CWE-1395
Allowed-with-ReviewDependency on Vulnerable Third-Party Component
Abstraction: Class · Status: Incomplete
The product has a dependency on a third-party component that contains one or more known vulnerabilities.
115 vulnerabilities reference this CWE, most recent first.
GHSA-W2JF-268Q-MRVH
Vulnerability from github – Published: 2025-11-06 15:44 – Updated: 2025-11-06 15:44Impact
Unauthenticated denial of service.
Summary
When installing module packages from attacker-controlled sources, tofu init may use unbounded memory, cause high CPU usage, or crash when encountering maliciously-crafted TLS certificate chains or tar archives.
Those who depend on modules or providers served from untrusted third-party servers may experience denial of service due to tofu init failing to complete successfully. In the case of unbounded memory usage or high CPU usage, other processes running on the same computer as OpenTofu may also fail or have their performance degraded due to the depletion of shared system resources.
These vulnerabilities do not permit arbitrary code execution or allow disclosure of confidential information.
Details
OpenTofu relies on third-party implementations of TLS certificate verification and tar archive extraction from the standard library of the Go programming language.
The Go project has recently published the following advisories for those implementations which indirectly affect OpenTofu's behavior:
- CVE-2025-58183: Unbounded allocation when parsing GNU sparse map in archive/tar
- CVE-2025-58185: Parsing DER payload can cause memory exhaustion in encoding/asn1
- CVE-2025-58187: Quadratic complexity when checking name constraints in crypto/x509
- CVE-2025-58188: Panic when validating certificates with DSA public keys in crypto/x509
OpenTofu's threat model considers module and package dependencies to be arbitrary third-party code that operators must carefully review after installation. However, these particular problems affect the process of installing these dependencies with tofu init, and so can potentially occur before an operator has had the opportunity to review what is being installed. In particular, the TLS-related vulnerabilities can occur before OpenTofu actually retrieves a dependency package and performs checksum verification, because they affect the transport of the packages rather than the content of the packages.
An attacker can exploit this either by controlling the TLS certificate chain used to authenticate the connection to the server where the dependencies are hosted, or (in the case of module packages only) by controlling the content of a package served when OpenTofu is expecting to receive a package using the "tar" archive format with or without compression.
However, the attacker must also coerce an OpenTofu operator into attempting dependency installation from the server they control. Typical use of OpenTofu already requires caution in selection of third-party dependencies because they are arbitrary code, and so the vulnerability here is only in the addition of a potential denial of service in the tofu init process, which does not execute third-party dependency code itself.
Patches
OpenTofu v1.10.7 addresses these vulnerabilities by being built against Go 1.24.9, which contains improved versions of the upstream implementations.
The OpenTofu v1.9 and v1.8 series are also impacted by these vulnerabilities. However, those series are built with a version of Go for which no upstream fix is available. Adopting Go 1.24.9 for those series would effectively end support for certain versions of macOS and Linux, and the OpenTofu Project has determined that the impact of these vulnerabilities is not high enough to justify that disruption in a patch release. For those using the OpenTofu v1.9 or v1.8 releases we recommend planning to upgrade to OpenTofu v1.10.7 in the near future, and reviewing the Workarounds section below in the meantime.
Workarounds
These vulnerabilities can be exploited only if an attacker can coerce an operator to add a dependency from an attacker-controlled source to their configuration before running tofu init. Those who are unable to upgrade can therefore minimize risk by reviewing new dependencies before adding them to the configuration, such as by directly fetching the relevant artifacts using software other than OpenTofu.
Successful exploitation requires that the attacker control either an HTTPS server that tofu init would contact during dependency installation or a tar archive that OpenTofu would fetch and extract during the module installation process. Note that OpenTofu modules can have their own dependencies on other modules, so an attacker could potentially use a module served from a source such as GitHub or the OpenTofu Registry to indirectly request a module from a server they control.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/opentofu/opentofu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-06T15:44:04Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\n\nUnauthenticated denial of service.\n\n### Summary\n\nWhen installing module packages from attacker-controlled sources, `tofu init` may use unbounded memory, cause high CPU usage, or crash when encountering maliciously-crafted TLS certificate chains or tar archives.\n\nThose who depend on modules or providers served from untrusted third-party servers may experience denial of service due to `tofu init` failing to complete successfully. In the case of unbounded memory usage or high CPU usage, other processes running on the same computer as OpenTofu may also fail or have their performance degraded due to the depletion of shared system resources.\n\nThese vulnerabilities **do not** permit arbitrary code execution or allow disclosure of confidential information.\n\n### Details\n\nOpenTofu relies on third-party implementations of TLS certificate verification and tar archive extraction from the standard library of the Go programming language.\n\nThe Go project has recently published the following advisories for those implementations which indirectly affect OpenTofu\u0027s behavior:\n\n- [CVE-2025-58183](https://www.cve.org/CVERecord?id=CVE-2025-58183): Unbounded allocation when parsing GNU sparse map in archive/tar\n- [CVE-2025-58185](https://www.cve.org/CVERecord?id=CVE-2025-58185): Parsing DER payload can cause memory exhaustion in encoding/asn1\n- [CVE-2025-58187](https://www.cve.org/CVERecord?id=CVE-2025-58187): Quadratic complexity when checking name constraints in crypto/x509\n- [CVE-2025-58188](https://www.cve.org/CVERecord?id=CVE-2025-58188): Panic when validating certificates with DSA public keys in crypto/x509\n\nOpenTofu\u0027s threat model considers module and package dependencies to be arbitrary third-party code that operators must carefully review after installation. However, these particular problems affect the process of _installing_ these dependencies with `tofu init`, and so can potentially occur before an operator has had the opportunity to review what is being installed. In particular, the TLS-related vulnerabilities can occur before OpenTofu actually retrieves a dependency package and performs checksum verification, because they affect the transport of the packages rather than the content of the packages.\n\nAn attacker can exploit this either by controlling the TLS certificate chain used to authenticate the connection to the server where the dependencies are hosted, or (in the case of module packages only) by controlling the content of a package served when OpenTofu is expecting to receive a package using the \"tar\" archive format with or without compression.\n\nHowever, the attacker must also coerce an OpenTofu operator into attempting dependency installation from the server they control. Typical use of OpenTofu already requires caution in selection of third-party dependencies because they are arbitrary code, and so the vulnerability here is only in the addition of a potential denial of service in the `tofu init` process, which does not execute third-party dependency code itself.\n\n### Patches\n\nOpenTofu v1.10.7 addresses these vulnerabilities by being built against Go 1.24.9, which contains improved versions of the upstream implementations.\n\nThe OpenTofu v1.9 and v1.8 series are also impacted by these vulnerabilities. However, those series are built with a version of Go for which no upstream fix is available. Adopting Go 1.24.9 for those series would effectively end support for certain versions of macOS and Linux, and the OpenTofu Project has determined that the impact of these vulnerabilities is not high enough to justify that disruption in a patch release. For those using the OpenTofu v1.9 or v1.8 releases we recommend planning to upgrade to OpenTofu v1.10.7 in the near future, and reviewing the Workarounds section below in the meantime.\n\n### Workarounds\n\nThese vulnerabilities can be exploited only if an attacker can coerce an operator to add a dependency from an attacker-controlled source to their configuration before running `tofu init`. Those who are unable to upgrade can therefore minimize risk by reviewing new dependencies _before_ adding them to the configuration, such as by directly fetching the relevant artifacts using software other than OpenTofu.\n\nSuccessful exploitation requires that the attacker control either an HTTPS server that `tofu init` would contact during dependency installation or a tar archive that OpenTofu would fetch and extract during the module installation process. Note that OpenTofu modules can have their own dependencies on other modules, so an attacker could potentially use a module served from a source such as GitHub or the OpenTofu Registry to indirectly request a module from a server they control.",
"id": "GHSA-w2jf-268q-mrvh",
"modified": "2025-11-06T15:44:04Z",
"published": "2025-11-06T15:44:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/security/advisories/GHSA-w2jf-268q-mrvh"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/3458"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/3462"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/3464"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/3465"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/pull/3467"
},
{
"type": "PACKAGE",
"url": "https://github.com/opentofu/opentofu"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/releases/tag/v1.10.7"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58183"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58185"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58187"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-58188"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "OpenTofu affected denials of service in \"tofu init\" with maliciously-crafted module package responses"
}
GHSA-W37M-7FHW-FMV9
Vulnerability from github – Published: 2025-12-11 22:49 – Updated: 2025-12-11 22:49A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as CVE-2025-55183.
A malicious HTTP request can be crafted and sent to any App Router endpoint that can return the compiled source code of Server Functions. This could reveal business logic, but would not expose secrets unless they were hardcoded directly into Server Function code.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.0.0-canary.0"
},
{
"fixed": "15.0.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.1.1-canary.0"
},
{
"fixed": "15.1.10"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.2.0-canary.0"
},
{
"fixed": "15.2.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.3.0-canary.0"
},
{
"fixed": "15.3.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.4.0-canary.0"
},
{
"fixed": "15.4.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.5.1-canary.0"
},
{
"fixed": "15.5.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "15.6.0-canary.0"
},
{
"fixed": "15.6.0-canary.59"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0-beta.0"
},
{
"fixed": "16.0.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "16.1.0-canary.0"
},
{
"fixed": "16.1.0-canary.17"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-497",
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-11T22:49:56Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as [CVE-2025-55183](https://www.cve.org/CVERecord?id=CVE-2025-55183).\n\nA malicious HTTP request can be crafted and sent to any App Router endpoint that can return the compiled source code of [Server Functions](https://react.dev/reference/rsc/server-functions). This could reveal business logic, but would not expose secrets unless they were hardcoded directly into [Server Function](https://react.dev/reference/rsc/server-functions) code.",
"id": "GHSA-w37m-7fhw-fmv9",
"modified": "2025-12-11T22:49:56Z",
"published": "2025-12-11T22:49:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/security/advisories/GHSA-w37m-7fhw-fmv9"
},
{
"type": "PACKAGE",
"url": "https://github.com/vercel/next.js"
},
{
"type": "WEB",
"url": "https://nextjs.org/blog/security-update-2025-12-11"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-55183"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Next Server Actions Source Code Exposure "
}
GHSA-WCHH-9X6H-7F6P
Vulnerability from github – Published: 2026-07-29 16:11 – Updated: 2026-07-29 16:11Problem
Multiple vulnerabilities were disclosed in 2024 affecting libolm (Olm): AES timing / side‑channel, Ed25519 signature malleability, and timing leaks in base64 decoding; several CVEs were assigned. Patches and mitigations were published; maintainers recommend upgrading to fixed versions. In addition, a 2022 “Olm/Megolm protocol confusion” advisory affecting some SDKs was critical and required client-side fixes. Use patched versions of libolm and up-to-date Matrix SDKs; avoid unpatched clients/servers.
Olm is a dependency of matrix-commander (Python version, not Rust version).
WARNING:
Due to cryptographic olm dependency deprecation, this program is cryptographically unsafe to use until https://github.com/matrix-nio/matrix-nio/pull/555 is merged. Good news: https://github.com/8go/matrix-commander-rs is a Rust alternative not having this issue.
References
- CVE-2022-39255
- CVE-2024-45193
- https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/
- https://nvd.nist.gov/nvd.cfm?cvename=CVE-2024-45193
- https://github.com/matrix-org/matrix-ios-sdk/security/advisories/GHSA-hw6g-j8v6-9hcm
Workarounds
- use the Rust version: https://github.com/8go/matrix-commander-rs
Severity:
Medium
CVE-2022-39255 — MEDIUM (NVD/MITRE lists CVSS base score 5.x — treated as Medium).
CVE-2024-45193 — MEDIUM (NVD shows CVSS 3.1 base score ~4.3 — Medium)
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "matrix-commander"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "8.0.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-29T16:11:45Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Problem\n\nMultiple vulnerabilities were disclosed in 2024 affecting libolm (Olm): AES timing / side\u2011channel, Ed25519 signature malleability, and timing leaks in base64 decoding; several CVEs were assigned. Patches and mitigations were published; maintainers recommend upgrading to fixed versions. In addition, a 2022 \u201cOlm/Megolm protocol confusion\u201d advisory affecting some SDKs was critical and required client-side fixes. Use patched versions of libolm and up-to-date Matrix SDKs; avoid unpatched clients/servers.\n\nOlm is a dependency of `matrix-commander` (Python version, not Rust version).\n\nWARNING:\n\nDue to cryptographic [olm dependency deprecation](https://github.com/8go/matrix-commander/issues/204#issuecomment-3523986979), this program is cryptographically unsafe to use until https://github.com/matrix-nio/matrix-nio/pull/555 is merged. Good news: https://github.com/8go/matrix-commander-rs is a Rust alternative not having this issue.\n\n\n### References\n- CVE-2022-39255\n- CVE-2024-45193\n- https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/\n- https://nvd.nist.gov/nvd.cfm?cvename=CVE-2024-45193\n- https://github.com/matrix-org/matrix-ios-sdk/security/advisories/GHSA-hw6g-j8v6-9hcm\n\n### Workarounds\n- use the Rust version: https://github.com/8go/matrix-commander-rs \n\n### Severity:\n\nMedium\n\nCVE-2022-39255 \u2014 MEDIUM (NVD/MITRE lists CVSS base score 5.x \u2014 treated as Medium).\n\nCVE-2024-45193 \u2014 MEDIUM (NVD shows CVSS 3.1 base score ~4.3 \u2014 Medium)",
"id": "GHSA-wchh-9x6h-7f6p",
"modified": "2026-07-29T16:11:45Z",
"published": "2026-07-29T16:11:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/8go/matrix-commander/security/advisories/GHSA-wchh-9x6h-7f6p"
},
{
"type": "WEB",
"url": "https://github.com/8go/matrix-commander/issues/204#issuecomment-3523986979"
},
{
"type": "WEB",
"url": "https://github.com/matrix-nio/matrix-nio/pull/555"
},
{
"type": "WEB",
"url": "https://github.com/matrix-nio/matrix-nio/commit/71a1c808bc2ae6ea2a6e8effa7c11bd09796c626"
},
{
"type": "PACKAGE",
"url": "https://github.com/8go/matrix-commander"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "olm dependency deprecation: CVE-2022-39255 and CVE-2024-45193"
}
GHSA-WCJX-V2WJ-XG87
Vulnerability from github – Published: 2026-03-26 22:27 – Updated: 2026-03-26 22:27Pin vulnerable version of pyasn, see: See: https://github.com/advisories/GHSA-jr27-m4p2-rc6r
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 1.1.65"
},
"package": {
"ecosystem": "PyPI",
"name": "c2cciutils"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.66"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T22:27:12Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Pin vulnerable version of pyasn, see: See: https://github.com/advisories/GHSA-jr27-m4p2-rc6r",
"id": "GHSA-wcjx-v2wj-xg87",
"modified": "2026-03-26T22:27:12Z",
"published": "2026-03-26T22:27:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/camptocamp/c2cciutils/security/advisories/GHSA-wcjx-v2wj-xg87"
},
{
"type": "WEB",
"url": "https://github.com/camptocamp/c2cciutils/commit/1ab415014817d7d1cf09ad56cc8a7dec2a1108d8"
},
{
"type": "PACKAGE",
"url": "https://github.com/camptocamp/c2cciutils"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "C2C CI utils is vulnerable to DoS via pyasn dependency (CVE-2026-30922)"
}
GHSA-X9P2-77V6-6VHF
Vulnerability from github – Published: 2026-02-05 18:02 – Updated: 2026-02-12 14:23Delayed propagation of security fixes in upstream base images
Summary
Vulnerability in base Docker images (PHP, Go, and Alpine) not automatically propagating to FrankenPHP images.
FrankenPHP's container images were previously built only when specific version tags were updated or when manual triggers were initiated. This meant that if an upstream base image (such as Alpine Linux or official PHP/Go images) received a security patch under an existing tag, the FrankenPHP image would remain on the older, vulnerable version of those base layers.
Impact
Users pulling FrankenPHP images may have been running environments with known vulnerabilities in underlying system libraries (e.g., libcrypto3) even if they were using the "latest" version of a specific FrankenPHP tag.
Specifically, this includes vulnerabilities recently patched in Alpine 3.20.9, 3.21.6, 3.22.3, and 3.23.3, such as CVE-2025-15467 (Remote Code Execution in libcrypto3).
Details
The issue was a lack of automated "staleness" detection in the CI/CD pipeline.
Unless explicitly told, our build server was building new Docker images only when a new tag for base images was created. However, base images such as Alpine, PHP, and Go usually overwrite existing Docker tags to apply security fixes, which wasn't triggering a new build on our side.
Patches
As of February 4, 2026, the CI/CD pipeline has been updated.
- Automated Detection: A daily check is now performed to compare the digest of local base images against upstream registries.
- Auto-Rebuild: If a change is detected in base images (even if the tag name remains the same), FrankenPHP images are automatically rebuilt and re-pushed.
Users are advised to pull the latest versions of their specific tags to receive these updates.
Workarounds
You can force a local rebuild of your environment using the --pull flag to ensure you are fetching the latest patched base layers:
docker pull dunglas/frankenphp:latest
# If building your own image based on FrankenPHP
docker build --pull -t my-app .
References
- Alpine Linux Security Advisories
- CVE-2025-15467 (RCE in libcrypto3)
Credits
Thanks to Tim Nelles for reporting and fixing this issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/dunglas/frankenphp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-05T18:02:25Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "# Delayed propagation of security fixes in upstream base images\n\n## Summary\n\n**Vulnerability in base Docker images (PHP, Go, and Alpine) not automatically propagating to FrankenPHP images.**\n\nFrankenPHP\u0027s container images were previously built only when specific version tags were updated or when manual triggers were initiated. This meant that if an upstream base image (such as Alpine Linux or official PHP/Go images) received a security patch under an existing tag, the FrankenPHP image would remain on the older, vulnerable version of those base layers.\n\n## Impact\n\nUsers pulling FrankenPHP images may have been running environments with known vulnerabilities in underlying system libraries (e.g., `libcrypto3`) even if they were using the \"latest\" version of a specific FrankenPHP tag.\n\nSpecifically, this includes vulnerabilities recently patched in **Alpine 3.20.9, 3.21.6, 3.22.3, and 3.23.3**, such as **CVE-2025-15467** (Remote Code Execution in `libcrypto3`).\n\n## Details\n\nThe issue was a lack of automated \"staleness\" detection in the CI/CD pipeline.\n\nUnless explicitly told, our build server was building new Docker images only when a new tag for base images was created. However, base images such as Alpine, PHP, and Go usually overwrite existing Docker tags to apply security fixes, which wasn\u0027t triggering a new build on our side.\n\n## Patches\n\nAs of **February 4, 2026**, the CI/CD pipeline has been updated.\n\n* **Automated Detection:** A daily check is now performed to compare the digest of local base images against upstream registries.\n* **Auto-Rebuild:** If a change is detected in base images (even if the tag name remains the same), FrankenPHP images are automatically rebuilt and re-pushed.\n\n**Users are advised to pull the latest versions of their specific tags to receive these updates.**\n\n## Workarounds\n\nYou can force a local rebuild of your environment using the `--pull` flag to ensure you are fetching the latest patched base layers:\n\n```bash\ndocker pull dunglas/frankenphp:latest\n# If building your own image based on FrankenPHP\ndocker build --pull -t my-app .\n```\n\n## References\n\n* [Alpine Linux Security Advisories](https://www.alpinelinux.org/posts/Alpine-3.20.9-3.21.6-3.22.3-3.23.3-released.html)\n* **CVE-2025-15467** (RCE in libcrypto3)\n\n## Credits\n\nThanks to [Tim Nelles](https://timnelles.de/) for reporting and fixing this issue.",
"id": "GHSA-x9p2-77v6-6vhf",
"modified": "2026-02-12T14:23:09Z",
"published": "2026-02-05T18:02:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/php/frankenphp/security/advisories/GHSA-x9p2-77v6-6vhf"
},
{
"type": "PACKAGE",
"url": "https://github.com/php/frankenphp"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "FrankenPHP has delayed propagation of security fixes in upstream base images"
}
Mitigation
In some industries such as healthcare [REF-1320] [REF-1322] or technologies such as the cloud [REF-1321], it might be unclear about who is responsible for applying patches for third-party vulnerabilities: the vendor, the operator/customer, or a separate service. Clarifying roles and responsibilities can be important to minimize confusion or unnecessary delay when third-party vulnerabilities are disclosed.
Mitigation
Require a Bill of Materials for all components and sub-components of the product. For software, require a Software Bill of Materials (SBOM) [REF-1247] [REF-1311].
Mitigation
Maintain a Bill of Materials for all components and sub-components of the product. For software, maintain a Software Bill of Materials (SBOM). According to [REF-1247], "An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships."
Mitigation
Actively monitor when a third-party component vendor announces vulnerability patches; fix the third-party component as soon as possible; and make it easy for operators/customers to obtain and apply the patch.
Mitigation
Continuously monitor changes in each of the product's components, especially when the changes indicate new vulnerabilities, end-of-life (EOL) plans, etc.
No CAPEC attack patterns related to this CWE.