AI Threat AlertCVE-2025-5917: libarchive: off-by-one 1-byte write in filename handling
LOWCVE-2025-5917 is an off-by-one error in libarchive's handling of file name prefixes and suffixes that causes a 1-byte out-of-bounds write (CWE-787) in versions before 3.8.0. Severity is low (CVSS 2.8): it needs local access, low privileges, and a user to open a crafted archive, and the impact is limited to availability. There is no public exploit, no Nuclei template, and no KEV listing, and no EPSS score is available, so there is no sign of exploitation in the wild. The reason to track it anyway is blast radius: libarchive is a transitive dependency in dozens of Red Hat OpenShift AI (rhoai) container images, including MLflow, KServe, KubeRay, notebook controllers and the model registry, and the package has 695 downstream dependents. Fold the libarchive 3.8.0+ fix (or the vendor-patched RHOAI/OpenShift images) into your normal patch cycle rather than treating it as an emergency, and prioritize any pipeline that extracts untrusted archives.
What is the risk?
Low overall. The attack vector is local, privileges are low, and user interaction is required. Confidentiality and integrity impact are rated none, and availability impact is low (a crash). A 1-byte heap overflow can in rare circumstances be chained into stronger primitives, but no such chain is known and there is no public exploit or scanner template. Exposure is wide because libarchive is embedded in many RHOAI and OpenShift images, so the main concern is patch hygiene across containers rather than the severity of any single instance. The package risk score of 81/100, 137 other CVEs in the same package, and an OpenSSF Scorecard of 5.4/10 indicate a library with a recurring memory-safety history.
How does the attack unfold?
What systems are affected?
How severe is it?
What is the attack surface?
What should I do?
5 stepsUpgrade libarchive to 3.8.0 or later, or apply the Red Hat errata for the affected rhoai and openshift images (see the Red Hat CVE page and Bugzilla 2370874).
Rebuild and redeploy container images that bundle a vulnerable libarchive, and refresh base images.
Avoid extracting archives from untrusted sources in privileged or shared contexts; run extraction in sandboxed, least-privilege containers.
Inventory with an SBOM scan (for example Syft or Grype) to find libarchive versions below 3.8.0 across ML images.
Monitor for repeated crashes or segfaults in archive-handling services, which could indicate attempted exploitation.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2025-5917?
CVE-2025-5917 is an off-by-one error in libarchive's handling of file name prefixes and suffixes that causes a 1-byte out-of-bounds write (CWE-787) in versions before 3.8.0. Severity is low (CVSS 2.8): it needs local access, low privileges, and a user to open a crafted archive, and the impact is limited to availability. There is no public exploit, no Nuclei template, and no KEV listing, and no EPSS score is available, so there is no sign of exploitation in the wild. The reason to track it anyway is blast radius: libarchive is a transitive dependency in dozens of Red Hat OpenShift AI (rhoai) container images, including MLflow, KServe, KubeRay, notebook controllers and the model registry, and the package has 695 downstream dependents. Fold the libarchive 3.8.0+ fix (or the vendor-patched RHOAI/OpenShift images) into your normal patch cycle rather than treating it as an emergency, and prioritize any pipeline that extracts untrusted archives.
Is CVE-2025-5917 actively exploited?
No confirmed active exploitation of CVE-2025-5917 has been reported, but organizations should still patch proactively.
How to fix CVE-2025-5917?
1. Upgrade libarchive to 3.8.0 or later, or apply the Red Hat errata for the affected rhoai and openshift images (see the Red Hat CVE page and Bugzilla 2370874). 2. Rebuild and redeploy container images that bundle a vulnerable libarchive, and refresh base images. 3. Avoid extracting archives from untrusted sources in privileged or shared contexts; run extraction in sandboxed, least-privilege containers. 4. Inventory with an SBOM scan (for example Syft or Grype) to find libarchive versions below 3.8.0 across ML images. 5. Monitor for repeated crashes or segfaults in archive-handling services, which could indicate attempted exploitation.
What systems are affected by CVE-2025-5917?
This vulnerability affects the following AI/ML architecture patterns: model serving, training pipelines, MLOps platforms, notebook and workbench environments, model registries, Kubernetes-based ML operators.
What is the CVSS score for CVE-2025-5917?
CVE-2025-5917 has a CVSS v3.1 base score of 2.8 (LOW).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001AI SoftwareAML.T0011.000Unsafe AI ArtifactsCompliance Controls Affected
What are the technical details?
Original Advisory
A vulnerability has been identified in the libarchive library. This flaw involves an 'off-by-one' miscalculation when handling prefixes and suffixes for file names. This can lead to a 1-byte write overflow. While seemingly small, such an overflow can corrupt adjacent memory, leading to unpredictable program behavior, crashes, or in specific circumstances, could be leveraged as a building block for more sophisticated exploitation. This bug affects libarchive versions prior to 3.8.0.
Exploitation Scenario
An attacker with low-privileged access to a shared data science environment uploads a crafted archive with specially sized file name prefix and suffix fields as a model bundle or dataset. When a colleague or an automated pipeline step extracts it using a vulnerable libarchive, the off-by-one write corrupts adjacent heap memory and crashes the extraction process. This disrupts the pipeline or notebook workbench, and a skilled attacker might attempt to turn the corruption into a more capable primitive, though no such technique is public.
Weaknesses (CWE)
CWE-787 — Out-of-bounds Write: The product writes data past the end, or before the beginning, of the intended buffer.
- [Requirements] Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
- [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:LReferences
- access.redhat.com/security/cve/CVE-2025-5917vdb-entryx_refsource_REDHAT
- bugzilla.redhat.com/show_bug.cgiissue-trackingx_refsource_REDHAT
- github.com/libarchive/libarchive/pull/2588
- github.com/libarchive/libarchive/releases/tag/v3.8.0
Timeline
Related Vulnerabilities
CVE-2025-1537910.0MLflow: RCE via unsanitized model dependency specs
Same package: mlflowCVE-2023-376510.0MLflow: path traversal allows arbitrary file read
Same package: mlflowCVE-2026-26359.8mlflow: security flaw enables exploitation
Same package: mlflowCVE-2023-27809.8MLflow: path traversal allows arbitrary file read/write
Same package: mlflowCVE-2023-11779.8MLflow: path traversal allows arbitrary file read/write
Same package: mlflow