Common Weakness Enumeration
CWE-672
Allowed-with-ReviewOperation on a Resource after Expiration or Release
Abstraction: Class · Status: Draft
The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
122 vulnerabilities reference this CWE, most recent first.
GHSA-X3RH-M7VP-35F2
Vulnerability from github – Published: 2020-08-05 14:52 – Updated: 2021-06-15 18:11
VLAI
Summary
Operation on a Resource after Expiration or Release in Jetty Server
Details
In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with response2 data. Thread1 then proceeds to write the buffer that now contains response2 data. This results in client1, which issued request1 and expects responses, to see response2 which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.).
Severity
9.4 (Critical)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.4.30.v20200610"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.4.27"
},
{
"fixed": "9.4.30.v20200611"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-17638"
],
"database_specific": {
"cwe_ids": [
"CWE-672",
"CWE-675"
],
"github_reviewed": true,
"github_reviewed_at": "2020-08-03T20:11:29Z",
"nvd_published_at": "2020-07-09T18:15:00Z",
"severity": "CRITICAL"
},
"details": "In Eclipse Jetty, versions 9.4.27.v20200227 to 9.4.29.v20200521, in case of too large response headers, Jetty throws an exception to produce an HTTP 431 error. When this happens, the ByteBuffer containing the HTTP response headers is released back to the ByteBufferPool twice. Because of this double release, two threads can acquire the same ByteBuffer from the pool and while thread1 is about to use the ByteBuffer to write response1 data, thread2 fills the ByteBuffer with response2 data. Thread1 then proceeds to write the buffer that now contains response2 data. This results in client1, which issued request1 and expects responses, to see response2 which could contain sensitive data belonging to client2 (HTTP session ids, authentication credentials, etc.).",
"id": "GHSA-x3rh-m7vp-35f2",
"modified": "2021-06-15T18:11:20Z",
"published": "2020-08-05T14:52:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17638"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/jetty.project/issues/4936"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/jetty.project/commit/ff8ae56fa939c3477a0cdd1ff56ce3d902f08fba"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGECLIPSEJETTY-575561"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XE6US6VPZHOWFMUSFGDS5V2DNQPY5MKB"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd98cfd012490cb02caa1a11aaa0cc38bff2d43bcce9b20c2f01063dd@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd0e44e8ef71eeaaa3cf3d1b8b41eb25894372e2995ec908ce7624d26@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbe1f230e87ea947593145d0072d0097ddb0af10fee1161db8ca1546c@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra8661fc8c69c647cb06153c1485d48484a833d873f75dfe45937e9de@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9a2cfa56d30782a0c17a5deb951a622d1f5c8de48e1c3b578ffc2a84@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r9584c4304c888f651d214341a939bd264ed30c9e3d0d30fe85097ecf@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r81f58591fb4716fb867b36956f30c7c8ad4ab3f23abc952d9d86a2a0@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7fc5f2ed49641ea91c433e3cd0fc3d31c0278c87b82b15c33b881415@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r521168299e023fb075b57afe33d17ff1d09e8a10e0fd8c775ea0e028@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4bdd3f7bb6820a79f9416b6667d718a06d269018619a75ce4b759318@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r378e4cdec15e132575aa1dcb6296ffeff2a896745a8991522e266ad4@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r29073905dc9139d0d7a146595694bf57bb9e35e5ec6aa73eb9c8443a@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://bugs.eclipse.org/bugs/show_bug.cgi?id=564984"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/08/17/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Operation on a Resource after Expiration or Release in Jetty Server"
}
GHSA-XMXX-7P24-H892
Vulnerability from github – Published: 2026-04-17 22:32 – Updated: 2026-05-12 13:35
VLAI
Summary
OpenClaw: Gateway HTTP endpoints re-resolve bearer auth after SecretRef rotation
Details
Summary
Gateway HTTP and WebSocket handlers captured the resolved bearer-auth configuration when the server started. After a SecretRef rotation, the already-running gateway could continue accepting the old bearer token until restart.
Impact
A bearer token that should have been revoked by SecretRef rotation could remain valid on the gateway HTTP and upgrade surfaces for the lifetime of the process. Severity remains high because the old token could continue to authorize gateway requests after operators believed it was rotated out.
Affected versions
- Affected:
< 2026.4.15 - Patched:
2026.4.15
Fix
OpenClaw 2026.4.15 resolves active gateway auth from the runtime secret snapshot per request and per upgrade instead of using a stale startup-time value.
Verified in v2026.4.15:
src/gateway/server.impl.tsexposesgetResolvedAuth()backed by the current runtime secret snapshot.src/gateway/server-http.tscallsgetResolvedAuth()for each HTTP request and WebSocket upgrade before running auth checks.src/gateway/server-http.probe.test.tsverifies/readyre-resolves bearer auth after rotation and rejects the old token.
Fix commit included in v2026.4.15 and absent from v2026.4.14:
acd4e0a32f12e1ad85f3130f63b42443ce90f094via PR #66651
Thanks to @zsxsoft, Keen Security Lab, and @qclawer for reporting this issue.
Severity
8.1 (High)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-43585"
],
"database_specific": {
"cwe_ids": [
"CWE-324",
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-17T22:32:02Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\nGateway HTTP and WebSocket handlers captured the resolved bearer-auth configuration when the server started. After a SecretRef rotation, the already-running gateway could continue accepting the old bearer token until restart.\n\n## Impact\n\nA bearer token that should have been revoked by SecretRef rotation could remain valid on the gateway HTTP and upgrade surfaces for the lifetime of the process. Severity remains high because the old token could continue to authorize gateway requests after operators believed it was rotated out.\n\n## Affected versions\n\n- Affected: `\u003c 2026.4.15`\n- Patched: `2026.4.15`\n\n## Fix\n\nOpenClaw `2026.4.15` resolves active gateway auth from the runtime secret snapshot per request and per upgrade instead of using a stale startup-time value.\n\nVerified in `v2026.4.15`:\n\n- `src/gateway/server.impl.ts` exposes `getResolvedAuth()` backed by the current runtime secret snapshot.\n- `src/gateway/server-http.ts` calls `getResolvedAuth()` for each HTTP request and WebSocket upgrade before running auth checks.\n- `src/gateway/server-http.probe.test.ts` verifies `/ready` re-resolves bearer auth after rotation and rejects the old token.\n\nFix commit included in `v2026.4.15` and absent from `v2026.4.14`:\n\n- `acd4e0a32f12e1ad85f3130f63b42443ce90f094` via PR #66651\n\nThanks to @zsxsoft, Keen Security Lab, and @qclawer for reporting this issue.",
"id": "GHSA-xmxx-7p24-h892",
"modified": "2026-05-12T13:35:23Z",
"published": "2026-04-17T22:32:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xmxx-7p24-h892"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43585"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/pull/66651"
},
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/commit/acd4e0a32f12e1ad85f3130f63b42443ce90f094"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-bearer-token-validation-bypass-via-stale-secretref-resolution"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Gateway HTTP endpoints re-resolve bearer auth after SecretRef rotation"
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.