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.
133 vulnerabilities reference this CWE, most recent first.
GHSA-56P6-QW3C-FQ2G
Vulnerability from github – Published: 2025-03-26 18:30 – Updated: 2025-06-09 18:12Summary
Since the user status is not checked when verifying a session token a suspended user can use the token generated in session auth mode to access the API despite their status.
Details
There is a check missing in verifySessionJWT to verify that a user is actually still active and allowed to access the API. Right now one can extract the session token obtained by, e.g. login in to the app while still active and then, after the user has been suspended continue to use that token until it expires.
PoC
- Create an active user
- Log in with that user and note the session cookie
- Suspend the user (and don't trigger an
/auth/refreshcall, as that invalidates the session - Access the API with
Authorization: Bearer <token>
Impact
This weakens the security of suspending users.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "directus"
},
"ranges": [
{
"events": [
{
"introduced": "10.10.0"
},
{
"fixed": "11.5.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@directus/api"
},
"ranges": [
{
"events": [
{
"introduced": "18.0.0"
},
{
"fixed": "24.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@directus/types"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.7"
},
{
"fixed": "13.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-30351"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-26T18:30:43Z",
"nvd_published_at": "2025-03-26T18:15:26Z",
"severity": "LOW"
},
"details": "### Summary\nSince the user status is not checked when verifying a session token a suspended user can use the token generated in session auth mode to access the API despite their status.\n\n### Details\nThere is a check missing in `verifySessionJWT` to verify that a user is actually still active and allowed to access the API. Right now one can extract the session token obtained by, e.g. login in to the app while still active and then, after the user has been suspended continue to use that token until it expires.\n\n### PoC\n* Create an active user\n* Log in with that user and note the session cookie\n* Suspend the user (and don\u0027t trigger an `/auth/refresh` call, as that invalidates the session\n* Access the API with `Authorization: Bearer \u003ctoken\u003e`\n\n### Impact\nThis weakens the security of suspending users.",
"id": "GHSA-56p6-qw3c-fq2g",
"modified": "2025-06-09T18:12:09Z",
"published": "2025-03-26T18:30:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/directus/directus/security/advisories/GHSA-56p6-qw3c-fq2g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30351"
},
{
"type": "WEB",
"url": "https://github.com/directus/directus/commit/ef179931c55b50c110feca8404901d5633940771"
},
{
"type": "PACKAGE",
"url": "https://github.com/directus/directus"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Suspended Directus user can continue to use session token to access API"
}
GHSA-57WX-M636-G3G8
Vulnerability from github – Published: 2024-01-19 22:12 – Updated: 2024-03-01 15:19Impact
An external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as permissive instead of strict) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain.
Mitigation
In Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a strict or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as permissive, audit and skip to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms.
Additionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.
Credit
The Notary Project extends its gratitude to Justin Cappos (@JustinCappos) for responsibly disclosing the issue.
_Note: we have updated threat model to include considerations for rollback attack.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/notaryproject/notation"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-23332"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-19T22:12:22Z",
"nvd_published_at": "2024-01-19T23:15:07Z",
"severity": "MODERATE"
},
"details": "### Impact\nAn external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as `permissive` instead of `strict`) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain.\n\n### Mitigation\nIn Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a `strict` or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as `permissive`, `audit` and `skip` to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms.\n\nAdditionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.\n\n### Credit\nThe Notary Project extends its gratitude to Justin Cappos (@JustinCappos) for responsibly disclosing the issue.\n\n_**Note:** we have updated [threat model](https://github.com/notaryproject/specifications/blob/main/threatmodels/notation-threatmodel.md) to include considerations for rollback attack.",
"id": "GHSA-57wx-m636-g3g8",
"modified": "2024-03-01T15:19:13Z",
"published": "2024-01-19T22:12:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/notaryproject/specifications/security/advisories/GHSA-57wx-m636-g3g8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23332"
},
{
"type": "WEB",
"url": "https://github.com/notaryproject/specifications/commit/cdabdd1042de2999c685fa5d422a785ded9c983a"
},
{
"type": "PACKAGE",
"url": "https://github.com/notaryproject/specifications"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Go package github.com/notaryproject/notation configured with permissive trust policies potentially susceptible to rollback attack from compromised registry"
}
GHSA-5C8V-93Q6-CJXJ
Vulnerability from github – Published: 2026-08-06 12:31 – Updated: 2026-08-07 00:31In Apache CXF's DefaultEncryptingOAuthDataProvider, revoked access tokens still decrypt successfully, and TokenIntrospectionService reports active:true. The same applies to refresh tokens. This violates the RFC stipulations that 'The authorization server MUST invalidate the token.' and 'introspection of a revoked token MUST return {"active":false}'. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.
{
"affected": [],
"aliases": [
"CVE-2026-68481"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-06T12:16:28Z",
"severity": "HIGH"
},
"details": "In Apache CXF\u0027s DefaultEncryptingOAuthDataProvider, revoked access tokens still decrypt successfully, and TokenIntrospectionService reports active:true. The same applies to refresh tokens. This violates the RFC stipulations that \u0027The authorization server MUST invalidate the token.\u0027 and \u0027introspection of a revoked token MUST return {\"active\":false}\u0027. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.",
"id": "GHSA-5c8v-93q6-cjxj",
"modified": "2026-08-07T00:31:10Z",
"published": "2026-08-06T12:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-68481"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/88c0h10yjb2b8201o1km3st71fs2zw2b"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/06/25"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5R25-M2H9-W299
Vulnerability from github – Published: 2025-10-15 15:30 – Updated: 2025-10-22 21:31When the BIG-IP Advanced WAF and ASM security policy and a server-side HTTP/2 profile are configured on a virtual server, undisclosed traffic can cause the Traffic Management Microkernel (TMM) to terminate. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.
{
"affected": [],
"aliases": [
"CVE-2025-55669"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-15T14:15:51Z",
"severity": "HIGH"
},
"details": "When the BIG-IP Advanced WAF and ASM security policy and a server-side HTTP/2 profile are configured on a virtual server, undisclosed traffic can cause the Traffic Management Microkernel (TMM) to terminate.\u00a0\u00a0Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
"id": "GHSA-5r25-m2h9-w299",
"modified": "2025-10-22T21:31:18Z",
"published": "2025-10-15T15:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55669"
},
{
"type": "WEB",
"url": "https://my.f5.com/manage/s/article/K000150752"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-655H-HG88-5QMF
Vulnerability from github – Published: 2025-08-22 17:34 – Updated: 2025-08-22 17:34The API of xcb::Connection has constructors which allow an arbitrary RawFd to be used as a socket connection. On either failure of these constructors or on the drop of Connection, it closes the associated file descriptor. Thus, a program which uses an OwnedFd (such as a UnixStream) as the file descriptor can close the file descriptor and continue to attempt using it or close an already-closed file descriptor, violating I/O safety.
Starting in version 1.6.0, xcb provides Connection::connect_with_fd and Connection::connect_with_fd_and_extensions as safe alternatives and deprecates the problematic functions.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "xcb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-666",
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-22T17:34:45Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "The API of `xcb::Connection` has constructors which allow an arbitrary `RawFd` to be used as a socket connection. On either failure of these constructors or on the drop of `Connection`, it closes the associated file descriptor. Thus, a program which uses an `OwnedFd` (such as a `UnixStream`) as the file descriptor can close the file descriptor and continue to attempt using it or close an already-closed file descriptor, violating I/O safety.\n\nStarting in version 1.6.0, `xcb` provides `Connection::connect_with_fd` and `Connection::connect_with_fd_and_extensions` as safe alternatives and deprecates the problematic functions.",
"id": "GHSA-655h-hg88-5qmf",
"modified": "2025-08-22T17:34:45Z",
"published": "2025-08-22T17:34:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/issues/167"
},
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/issues/282"
},
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/pull/283"
},
{
"type": "WEB",
"url": "https://github.com/rustsec/advisory-db/pull/2355"
},
{
"type": "WEB",
"url": "https://github.com/rust-x-bindings/rust-xcb/commit/da830976870c1174e3b33eb0643177be3991c002"
},
{
"type": "PACKAGE",
"url": "https://github.com/rust-x-bindings/rust-xcb"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0051.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Rust XCB `xcb::Connection::connect_to_fd*` functions violate I/O safety"
}
GHSA-675F-RQ2R-JW82
Vulnerability from github – Published: 2025-01-09 17:23 – Updated: 2025-01-09 18:57Impact
The project's provided HTTP client's local JWK Set cache should do a full replacement when the goroutine refreshes the remote JWK Set. The current behavior is to overwrite or append. This is a security issue for use cases that utilize the provided auto-caching HTTP client and where key removal from a JWK Set is equivalent to revocation.
Example attack scenario:
1. An attacker has stolen the private key for a key published in JWK Set.
2. The publishers of that JWK Set remove that key from the JWK Set.
3. Enough time has passed that the program using the auto-caching HTTP client found in github.com/MicahParks/jwkset v0.5.0-v0.5.21 has elapsed its HTTPClientStorageOptions.RefreshInterval duration, causing a refresh of the remote JWK Set.
4. The attacker is signing content (such as JWTs) with the stolen private key and the system has no other forms of revocation.
Patches
The affected auto-caching HTTP client was added in version v0.5.0 and fixed in v0.6.0. Upgrade to v0.6.0 or later.
Workarounds
The only workaround would be to remove the provided auto-caching HTTP client and replace it with a custom implementation. This involves setting the HTTPClientStorageOptions.RefreshInterval to zero (or not specifying the value). Upgrade to v0.6.0 is advised.
References
Please see the tracking issue on GitHub for additional details: https://github.com/MicahParks/jwkset/issues/40
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.5.21"
},
"package": {
"ecosystem": "Go",
"name": "github.com/MicahParks/jwkset"
},
"ranges": [
{
"events": [
{
"introduced": "0.5.0"
},
{
"fixed": "0.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-22149"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-09T17:23:43Z",
"nvd_published_at": "2025-01-09T18:15:30Z",
"severity": "LOW"
},
"details": "### Impact\nThe project\u0027s provided HTTP client\u0027s local JWK Set cache should do a full replacement when the goroutine refreshes the remote JWK Set. The current behavior is to overwrite or append. This is a security issue for use cases that utilize the provided auto-caching HTTP client and where key removal from a JWK Set is equivalent to revocation.\n\nExample attack scenario:\n1. An attacker has stolen the private key for a key published in JWK Set.\n2. The publishers of that JWK Set remove that key from the JWK Set.\n3. Enough time has passed that the program using the auto-caching HTTP client found in `github.com/MicahParks/jwkset` v0.5.0-v0.5.21 has elapsed its `HTTPClientStorageOptions.RefreshInterval` duration, causing a refresh of the remote JWK Set.\n4. The attacker is signing content (such as JWTs) with the stolen private key and the system has no other forms of revocation.\n\n### Patches\nThe affected auto-caching HTTP client was added in version `v0.5.0` and fixed in `v0.6.0`. Upgrade to `v0.6.0` or later.\n\n### Workarounds\nThe only workaround would be to remove the provided auto-caching HTTP client and replace it with a custom implementation. This involves setting the `HTTPClientStorageOptions.RefreshInterval` to zero (or not specifying the value). Upgrade to `v0.6.0` is advised.\n\n### References\nPlease see the tracking issue on GitHub for additional details: https://github.com/MicahParks/jwkset/issues/40\n",
"id": "GHSA-675f-rq2r-jw82",
"modified": "2025-01-09T18:57:32Z",
"published": "2025-01-09T17:23:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MicahParks/jwkset/security/advisories/GHSA-675f-rq2r-jw82"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22149"
},
{
"type": "WEB",
"url": "https://github.com/MicahParks/jwkset/issues/40"
},
{
"type": "WEB",
"url": "https://github.com/MicahParks/jwkset/pull/41"
},
{
"type": "WEB",
"url": "https://github.com/MicahParks/jwkset/commit/01db49a90f7f20c7fb39a699a2f19a7a5f379ed3"
},
{
"type": "PACKAGE",
"url": "https://github.com/MicahParks/jwkset"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "JWK Set\u0027s HTTP client only overwrites and appends JWK to local cache during refresh"
}
GHSA-67R5-RQWV-9P9Q
Vulnerability from github – Published: 2025-03-31 16:13 – Updated: 2025-03-31 16:13The Drop implementation will get run twice when using the cursor.
This issue does not affect you, if you are using only using the crate with types that are Copy such as u8.
This issue also does not affect you, if you are only depending on it through the crate planus.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "array-init-cursor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-31T16:13:34Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "The `Drop` implementation will get run twice when using the cursor.\n\nThis issue does not affect you, if you are using only using the crate with types that are `Copy` such as `u8`.\n\nThis issue also does not affect you, if you are only depending on it through the crate `planus`.",
"id": "GHSA-67r5-rqwv-9p9q",
"modified": "2025-03-31T16:13:34Z",
"published": "2025-03-31T16:13:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/planus-org/planus/issues/293"
},
{
"type": "WEB",
"url": "https://github.com/planus-org/planus/pull/294"
},
{
"type": "PACKAGE",
"url": "https://github.com/planus-org/planus"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2025-0019.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "array-init-cursor is unsound when used with types that implement `Drop`"
}
GHSA-6FVH-VVX6-69V5
Vulnerability from github – Published: 2025-01-08 03:30 – Updated: 2025-01-08 03:30UAF vulnerability in the device node access module Impact: Successful exploitation of this vulnerability may cause service exceptions of the device.
{
"affected": [],
"aliases": [
"CVE-2024-56434"
],
"database_specific": {
"cwe_ids": [
"CWE-416",
"CWE-672"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-08T02:15:25Z",
"severity": "MODERATE"
},
"details": "UAF vulnerability in the device node access module\nImpact: Successful exploitation of this vulnerability may cause service exceptions of the device.",
"id": "GHSA-6fvh-vvx6-69v5",
"modified": "2025-01-08T03:30:23Z",
"published": "2025-01-08T03:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56434"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2025/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6XMX-4966-5MWP
Vulnerability from github – Published: 2025-06-12 21:30 – Updated: 2025-06-12 21:30Amazon Cloud Cam is a home security camera that was deprecated on December 2, 2022, is end of life, and is no longer actively supported.
When a user powers on the Amazon Cloud Cam, the device attempts to connect to a remote service infrastructure that has been deprecated due to end-of-life status. The device defaults to a pairing status in which an arbitrary user can bypass SSL pinning to associate the device to an arbitrary network, allowing for network traffic interception and modification.
We recommend customers discontinue usage of any remaining Amazon Cloud Cams.
{
"affected": [],
"aliases": [
"CVE-2025-6031"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-12T20:15:22Z",
"severity": "HIGH"
},
"details": "Amazon Cloud Cam is a home security camera that was deprecated on December 2, 2022, is end of life, and is no longer actively supported. \n\nWhen a user powers on the Amazon Cloud Cam, the device attempts to connect to a remote service infrastructure that has been deprecated due to end-of-life status. The device defaults to a pairing status in which an arbitrary user can bypass SSL pinning to associate the device to an arbitrary network, allowing for network traffic interception and modification.\n\nWe recommend customers discontinue usage of any remaining Amazon Cloud Cams.",
"id": "GHSA-6xmx-4966-5mwp",
"modified": "2025-06-12T21:30:31Z",
"published": "2025-06-12T21:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6031"
},
{
"type": "WEB",
"url": "https://aws.amazon.com/security/security-bulletins/AWS-2025-013"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-86J3-8QQW-575J
Vulnerability from github – Published: 2022-05-24 17:05 – Updated: 2026-04-24 15:32An invalid memory address dereference was discovered in load_pnm in frompnm.c in libsixel before 1.8.3.
{
"affected": [],
"aliases": [
"CVE-2019-20022"
],
"database_specific": {
"cwe_ids": [
"CWE-672"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-12-27T02:15:00Z",
"severity": "MODERATE"
},
"details": "An invalid memory address dereference was discovered in load_pnm in frompnm.c in libsixel before 1.8.3.",
"id": "GHSA-86j3-8qqw-575j",
"modified": "2026-04-24T15:32:16Z",
"published": "2022-05-24T17:05:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20022"
},
{
"type": "WEB",
"url": "https://github.com/saitoha/libsixel/issues/108"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
No CAPEC attack patterns related to this CWE.