Monthly
Cross-user state leakage in Lookyloo's PlaywrightCapture Python library allows one capture operation to inherit sensitive data from another when multiple Capture objects run within the same Python process. Because capture-specific settings (HTTP headers, cookies, browser storage, HTTP credentials, proxy, user-agent, geolocation) were stored as mutable class-level rather than instance-level variables, a concurrent or subsequent capture in a multi-user deployment can disclose or reuse another user's authentication cookies, credentials, and captured request data. Exploitation requires low privileges (PR:L, a legitimate user of a shared deployment); a vendor patch exists (commit 1e354b9) and no public exploit identified at time of analysis.
Insufficient session invalidation in the Grav API plugin (getgrav/grav-plugin-api) before 2.0.4 renders stolen JWT access tokens permanently valid for up to one hour post-compromise. Because tokens are issued without a jti (JWT ID) claim, the server retains no mechanism to selectively revoke them - meaning logout events, password resets, new token issuance, and even account disablement are all ineffective at terminating an active attacker's session. No active exploitation is confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis; however, the CVSS 4.0 vector (AV:N/AC:L/PR:N) reflects that any attacker already in possession of a token can trivially exploit this revocation gap over the network.
Remote code execution in Open WebUI (self-hosted LLM interface) before the fixed 0.3.33 release allows attackers to hijack an authenticated admin session through a CORS misconfiguration. When an instance is deployed with allow_origins=* and an authenticated admin visits an attacker-controlled website, the malicious page can issue authenticated cross-origin requests to the /api/v1/functions endpoint and register attacker-supplied Python code, achieving code execution - and because the container runs as root by default, full container compromise. There is no public exploit identified at time of analysis and it is not on CISA KEV, but the flaw is documented in a GitHub Security Lab advisory (GHSL-2024-174/175) and reported by VulnCheck.
ColdFusion is affected by an Insufficient Session Expiration vulnerability that could result in a Security feature bypass. A high-privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction.
The `nebula-mgmt` Web UI host-creation path ignores both the server-wide `enrollment_token_ttl` security setting and per-network `network_config.enrollment_token_ttl` overrides. API host creation and token-regeneration paths use the configured TTL resolver, but `POST /ui/hosts` hardcodes `now.Add(24 * time.Hour)` for newly minted agent enrollment tokens. In deployments that intentionally reduce enrollment-token lifetime, any authenticated operator who can create a host through the Web UI can still mint a bearer enrollment token valid for about 24 hours. Enrollment tokens are bearer credentials for the public `POST /api/v1/enroll` endpoint: possession of a valid token allows enrolling the pending host and receiving a signed Nebula certificate/config for that host. The server configuration documents a security knob for their default lifetime and per-network overrides: - `internal/config/server.go:82` defines `EnrollmentTokenTTL` as the default lifetime for freshly minted enrollment tokens. - `internal/config/server.go:83` documents per-network overrides in `network_config` under `enrollment_token_ttl`. The API server implements and consistently uses this resolver: - `internal/api/server.go:77` defines `tokenTTLFor`, with precedence of per-network `enrollment_token_ttl`, then server default, then 24h fallback. - `internal/api/server.go:82` reads `network_config.enrollment_token_ttl`. - `internal/api/server.go:89` falls back to the configured server default. - `internal/api/hosts.go:190` through `internal/api/hosts.go:196` use `now.Add(s.tokenTTLFor(r.Context(), host.NetworkID))` for API host creation. The Web UI sibling path does not call the resolver and instead always sets a 24-hour expiry: - `internal/web/handlers.go:874` mints the raw token for `POST /ui/hosts`. - `internal/web/handlers.go:879` sets `ExpiresAt: now.Add(24 * time.Hour)`. This creates inconsistent behavior between API and Web UI host creation and bypasses an operator-configured token lifetime policy. The issue is reachable by an authenticated Web UI operator who can create hosts. Admins can create hosts in any network; non-admin operators can create hosts in networks whose CA they own. Affected version evidence: the configurable enrollment-token TTL feature was introduced by commit `6c344a6` (`feat(api): configurable enrollment-token TTL + regenerate endpoint (#75) (#79)`), and `git tag --contains 6c344a6 --sort=version:refname` returns `v0.3.0` through `v0.3.8`. Pattern checks across all release tags showed the TTL config/API resolver and the Web UI 24-hour hardcode are present in every `v0.3.x` release from `v0.3.0` to `v0.3.8`, and are not meaningfully applicable to `v0.1.x`/`v0.2.0` because the TTL policy knob was not present there. 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 only in-memory SQLite and `httptest`; it does not start a real server and does not contact external services. 1. Create a temporary test file `internal/web/security_audit_poc_test.go` in package `web`. 2. In the test, create an in-memory Web UI with `newTestWeb(t)`, create a network `audit-poc-net` with CIDR `10.77.0.0/24`, and set `network_config.enrollment_token_ttl` to `30m`. 3. Log in as the seeded test admin through the normal Web UI helper and obtain a CSRF token from `GET /ui/hosts/new`. 4. Submit `POST /ui/hosts` with `network_id=audit-poc-net`, `name=audit-poc-host`, `nebula_ips=10.77.0.10`, `role=host`, and `kind=agent`. 5. Parse the one-shot enrollment token from the returned host-detail page and read the token row with `GetEnrollmentToken`. 6. Compare the observed expiry to the configured 30-minute network override. Command run: ```bash go test ./internal/web -run 'TestSecurityAuditPOC' -count=1 -v ``` Observed vulnerable output from this environment: ```text === RUN TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL POC_UI_TTL_BYPASS observed_token_ttl=24h0m0s configured_network_ttl=30m expires_at=2026-06-13T14:51:45Z --- PASS: TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL (0.05s) ``` The meaningful control is the API sibling: `internal/api/hosts.go:190` through `internal/api/hosts.go:196` uses `s.tokenTTLFor(...)`, and existing tests in `internal/api/hosts_token_ttl_test.go` verify API-created/regenerated enrollment tokens honor server-default and per-network TTLs. Variant review also found API regenerate-token, API re-enroll, and signed-poll rekey token minting use the resolver rather than a hardcoded 24h value. 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. An authenticated Web UI operator can bypass a configured enrollment-token lifetime policy and obtain a token valid for approximately 24 hours even when the deployment or network is configured for a much shorter lifetime such as 30 minutes. Because enrollment tokens are bearer credentials for the public enrollment endpoint, longer-than-intended validity increases the window in which a copied, logged, shared, or otherwise exposed token can be used to enroll the pending host and obtain its Nebula certificate/config. This weakens confidentiality and integrity for deployments relying on short token lifetimes to reduce enrollment-token exposure. Suggested remediation: refactor the Web UI host-creation path to use the same TTL resolution as the API path, or move the resolver into a shared package/service used by both API and Web UI. Add a regression test under `internal/web` that sets `network_config.enrollment_token_ttl = "30m"`, creates an agent host through `POST /ui/hosts`, and asserts the persisted enrollment token expires within the configured 30-minute window rather than 24 hours.
Backend resource exhaustion in Hydro-Québec's Le Circuit Electrique EV charging station backend (all versions prior to the June 2026 fix) lets remote unauthenticated attackers open multiple simultaneous OCPP sessions under a single charging station identifier, flooding the platform with rogue clients. Because the backend never enforces one active session per station ID, an attacker can spin up many spoofed OCPP clients and exhaust backend capacity, degrading or denying service to legitimate charging stations. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; EPSS data was not provided.
Insufficient JWT expiration enforcement in ZITADEL's external JWT Identity Provider integration allows tokens lacking the `exp` claim to be treated as indefinitely valid, bypassing intended session lifetime controls. Versions 3.0.0-rc.1 through 3.4.11 and 4.0.0-rc.1 through 4.15.1 are affected, with the flaw residing in `internal/idp/providers/jwt/session.go`. An attacker who can obtain or craft a JWT from a configured trusted external issuer that omits the `exp` claim can maintain persistent authenticated access without re-authentication. No public exploit identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Insufficient session expiration in ZITADEL's external JWT Identity Provider allows arbitrarily old tokens from trusted issuers to pass authentication when the token omits the iat (issued-at) claim. ZITADEL versions prior to 3.4.12 (v3 branch) and 4.15.2 (v4 branch) are affected. An attacker holding a previously issued JWT from a trusted external IdP - specifically one lacking the iat claim - can reuse that token indefinitely, bypassing intended session expiry controls and maintaining unauthorized access. No public exploit identified at time of analysis.
Authentication bypass via capture-replay in Apache IoTDB (1.0.0 through 2.0.9) lets attackers reuse stale credentials against the REST interface because Basic Authentication continues to accept cached credentials that should have been invalidated. An attacker who has captured or previously held valid credentials can keep authenticating after those credentials should have expired or been revoked, gaining full read/write control of the time-series database. No public exploit identified at time of analysis, and EPSS is low (0.18%, 8th percentile), so no active exploitation is indicated despite the 9.8 CVSS.
Certificate revocation in nebula-mgmt (forgekeep/nebula-mesh ≤ v0.3.6) is non-durable due to two distinct authorization gaps at certificate issuance time. Blocked hosts bypass blocklist enforcement entirely by re-enrolling with a new token because `enroll.go:128` calls `caMgr.Sign()` without consulting the blocklist - a fingerprint-keyed structure that treats any fresh certificate as unknown. Separately, hosts enrolled under a subsequently-disabled operator auto-renew certificates indefinitely because `signHostCert` never re-validates operator or CA lifecycle status, meaning operator offboarding does not terminate provisioned host access. No public exploit is identified at time of analysis; both issues were discovered during an internal offensive security audit (tracking issue #178).
Cross-user state leakage in Lookyloo's PlaywrightCapture Python library allows one capture operation to inherit sensitive data from another when multiple Capture objects run within the same Python process. Because capture-specific settings (HTTP headers, cookies, browser storage, HTTP credentials, proxy, user-agent, geolocation) were stored as mutable class-level rather than instance-level variables, a concurrent or subsequent capture in a multi-user deployment can disclose or reuse another user's authentication cookies, credentials, and captured request data. Exploitation requires low privileges (PR:L, a legitimate user of a shared deployment); a vendor patch exists (commit 1e354b9) and no public exploit identified at time of analysis.
Insufficient session invalidation in the Grav API plugin (getgrav/grav-plugin-api) before 2.0.4 renders stolen JWT access tokens permanently valid for up to one hour post-compromise. Because tokens are issued without a jti (JWT ID) claim, the server retains no mechanism to selectively revoke them - meaning logout events, password resets, new token issuance, and even account disablement are all ineffective at terminating an active attacker's session. No active exploitation is confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis; however, the CVSS 4.0 vector (AV:N/AC:L/PR:N) reflects that any attacker already in possession of a token can trivially exploit this revocation gap over the network.
Remote code execution in Open WebUI (self-hosted LLM interface) before the fixed 0.3.33 release allows attackers to hijack an authenticated admin session through a CORS misconfiguration. When an instance is deployed with allow_origins=* and an authenticated admin visits an attacker-controlled website, the malicious page can issue authenticated cross-origin requests to the /api/v1/functions endpoint and register attacker-supplied Python code, achieving code execution - and because the container runs as root by default, full container compromise. There is no public exploit identified at time of analysis and it is not on CISA KEV, but the flaw is documented in a GitHub Security Lab advisory (GHSL-2024-174/175) and reported by VulnCheck.
ColdFusion is affected by an Insufficient Session Expiration vulnerability that could result in a Security feature bypass. A high-privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction.
The `nebula-mgmt` Web UI host-creation path ignores both the server-wide `enrollment_token_ttl` security setting and per-network `network_config.enrollment_token_ttl` overrides. API host creation and token-regeneration paths use the configured TTL resolver, but `POST /ui/hosts` hardcodes `now.Add(24 * time.Hour)` for newly minted agent enrollment tokens. In deployments that intentionally reduce enrollment-token lifetime, any authenticated operator who can create a host through the Web UI can still mint a bearer enrollment token valid for about 24 hours. Enrollment tokens are bearer credentials for the public `POST /api/v1/enroll` endpoint: possession of a valid token allows enrolling the pending host and receiving a signed Nebula certificate/config for that host. The server configuration documents a security knob for their default lifetime and per-network overrides: - `internal/config/server.go:82` defines `EnrollmentTokenTTL` as the default lifetime for freshly minted enrollment tokens. - `internal/config/server.go:83` documents per-network overrides in `network_config` under `enrollment_token_ttl`. The API server implements and consistently uses this resolver: - `internal/api/server.go:77` defines `tokenTTLFor`, with precedence of per-network `enrollment_token_ttl`, then server default, then 24h fallback. - `internal/api/server.go:82` reads `network_config.enrollment_token_ttl`. - `internal/api/server.go:89` falls back to the configured server default. - `internal/api/hosts.go:190` through `internal/api/hosts.go:196` use `now.Add(s.tokenTTLFor(r.Context(), host.NetworkID))` for API host creation. The Web UI sibling path does not call the resolver and instead always sets a 24-hour expiry: - `internal/web/handlers.go:874` mints the raw token for `POST /ui/hosts`. - `internal/web/handlers.go:879` sets `ExpiresAt: now.Add(24 * time.Hour)`. This creates inconsistent behavior between API and Web UI host creation and bypasses an operator-configured token lifetime policy. The issue is reachable by an authenticated Web UI operator who can create hosts. Admins can create hosts in any network; non-admin operators can create hosts in networks whose CA they own. Affected version evidence: the configurable enrollment-token TTL feature was introduced by commit `6c344a6` (`feat(api): configurable enrollment-token TTL + regenerate endpoint (#75) (#79)`), and `git tag --contains 6c344a6 --sort=version:refname` returns `v0.3.0` through `v0.3.8`. Pattern checks across all release tags showed the TTL config/API resolver and the Web UI 24-hour hardcode are present in every `v0.3.x` release from `v0.3.0` to `v0.3.8`, and are not meaningfully applicable to `v0.1.x`/`v0.2.0` because the TTL policy knob was not present there. 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 only in-memory SQLite and `httptest`; it does not start a real server and does not contact external services. 1. Create a temporary test file `internal/web/security_audit_poc_test.go` in package `web`. 2. In the test, create an in-memory Web UI with `newTestWeb(t)`, create a network `audit-poc-net` with CIDR `10.77.0.0/24`, and set `network_config.enrollment_token_ttl` to `30m`. 3. Log in as the seeded test admin through the normal Web UI helper and obtain a CSRF token from `GET /ui/hosts/new`. 4. Submit `POST /ui/hosts` with `network_id=audit-poc-net`, `name=audit-poc-host`, `nebula_ips=10.77.0.10`, `role=host`, and `kind=agent`. 5. Parse the one-shot enrollment token from the returned host-detail page and read the token row with `GetEnrollmentToken`. 6. Compare the observed expiry to the configured 30-minute network override. Command run: ```bash go test ./internal/web -run 'TestSecurityAuditPOC' -count=1 -v ``` Observed vulnerable output from this environment: ```text === RUN TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL POC_UI_TTL_BYPASS observed_token_ttl=24h0m0s configured_network_ttl=30m expires_at=2026-06-13T14:51:45Z --- PASS: TestSecurityAuditPOC_UIHostCreateIgnoresNetworkEnrollmentTokenTTL (0.05s) ``` The meaningful control is the API sibling: `internal/api/hosts.go:190` through `internal/api/hosts.go:196` uses `s.tokenTTLFor(...)`, and existing tests in `internal/api/hosts_token_ttl_test.go` verify API-created/regenerated enrollment tokens honor server-default and per-network TTLs. Variant review also found API regenerate-token, API re-enroll, and signed-poll rekey token minting use the resolver rather than a hardcoded 24h value. 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. An authenticated Web UI operator can bypass a configured enrollment-token lifetime policy and obtain a token valid for approximately 24 hours even when the deployment or network is configured for a much shorter lifetime such as 30 minutes. Because enrollment tokens are bearer credentials for the public enrollment endpoint, longer-than-intended validity increases the window in which a copied, logged, shared, or otherwise exposed token can be used to enroll the pending host and obtain its Nebula certificate/config. This weakens confidentiality and integrity for deployments relying on short token lifetimes to reduce enrollment-token exposure. Suggested remediation: refactor the Web UI host-creation path to use the same TTL resolution as the API path, or move the resolver into a shared package/service used by both API and Web UI. Add a regression test under `internal/web` that sets `network_config.enrollment_token_ttl = "30m"`, creates an agent host through `POST /ui/hosts`, and asserts the persisted enrollment token expires within the configured 30-minute window rather than 24 hours.
Backend resource exhaustion in Hydro-Québec's Le Circuit Electrique EV charging station backend (all versions prior to the June 2026 fix) lets remote unauthenticated attackers open multiple simultaneous OCPP sessions under a single charging station identifier, flooding the platform with rogue clients. Because the backend never enforces one active session per station ID, an attacker can spin up many spoofed OCPP clients and exhaust backend capacity, degrading or denying service to legitimate charging stations. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; EPSS data was not provided.
Insufficient JWT expiration enforcement in ZITADEL's external JWT Identity Provider integration allows tokens lacking the `exp` claim to be treated as indefinitely valid, bypassing intended session lifetime controls. Versions 3.0.0-rc.1 through 3.4.11 and 4.0.0-rc.1 through 4.15.1 are affected, with the flaw residing in `internal/idp/providers/jwt/session.go`. An attacker who can obtain or craft a JWT from a configured trusted external issuer that omits the `exp` claim can maintain persistent authenticated access without re-authentication. No public exploit identified at time of analysis, and the vulnerability is not listed in CISA KEV.
Insufficient session expiration in ZITADEL's external JWT Identity Provider allows arbitrarily old tokens from trusted issuers to pass authentication when the token omits the iat (issued-at) claim. ZITADEL versions prior to 3.4.12 (v3 branch) and 4.15.2 (v4 branch) are affected. An attacker holding a previously issued JWT from a trusted external IdP - specifically one lacking the iat claim - can reuse that token indefinitely, bypassing intended session expiry controls and maintaining unauthorized access. No public exploit identified at time of analysis.
Authentication bypass via capture-replay in Apache IoTDB (1.0.0 through 2.0.9) lets attackers reuse stale credentials against the REST interface because Basic Authentication continues to accept cached credentials that should have been invalidated. An attacker who has captured or previously held valid credentials can keep authenticating after those credentials should have expired or been revoked, gaining full read/write control of the time-series database. No public exploit identified at time of analysis, and EPSS is low (0.18%, 8th percentile), so no active exploitation is indicated despite the 9.8 CVSS.
Certificate revocation in nebula-mgmt (forgekeep/nebula-mesh ≤ v0.3.6) is non-durable due to two distinct authorization gaps at certificate issuance time. Blocked hosts bypass blocklist enforcement entirely by re-enrolling with a new token because `enroll.go:128` calls `caMgr.Sign()` without consulting the blocklist - a fingerprint-keyed structure that treats any fresh certificate as unknown. Separately, hosts enrolled under a subsequently-disabled operator auto-renew certificates indefinitely because `signHostCert` never re-validates operator or CA lifecycle status, meaning operator offboarding does not terminate provisioned host access. No public exploit is identified at time of analysis; both issues were discovered during an internal offensive security audit (tracking issue #178).