<Vulnerability name="CVE-2026-112910">
    <DocumentDistribution xml:lang="en">Copyright © 2012 Red Hat, Inc. All rights reserved.</DocumentDistribution>
    <ThreatSeverity>Moderate</ThreatSeverity>
    <PublicDate>2026-11-05T21:47:35</PublicDate>
    <Bugzilla id="2567560" url="https://bugzilla.redhat.com/show_bug.cgi?id=2567560" xml:lang="en:us">
filelock: filelock: Denial of Service via improper lock file permissions on Windows
    </Bugzilla>
    <CVSS3 status="draft">
        <CVSS3BaseScore>5.3</CVSS3BaseScore>
        <CVSS3ScoringVector>CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L</CVSS3ScoringVector>
    </CVSS3>
    <CWE>CWE-279</CWE>
    <Details xml:lang="en:us" source="Mitre">
filelock is a platform-independent file lock for Python. From 3.10.0 until 4.2.1, filelock on Windows ignores the mode argument for WindowsFileLock files and the ReadWriteLock SQLite database. A lock created with mode=0o600 receives the parent directory's inheritable ACL because _open_non_reparse_fd and _nt_open do not create an owner-only security descriptor. Another local account with inherited access can read holder metadata or the lock database, modify those files where the ACL permits writes, or take the byte-range lock after release and delay later acquisitions. UnixFileLock is not affected, and mutual exclusion between cooperating processes continues to hold. This issue is fixed in version 4.2.1.
    </Details>
    <Details xml:lang="en:us" source="Red Hat">
A flaw was found in filelock. On Windows platforms, the library ignores requested file mode permissions when creating lock files and database files, causing them to inherit default permissions from the parent directory's access control list (ACL). A local user on the same system can exploit this flaw to cause a Denial of Service (DoS) by taking the lock and blocking legitimate processes, read lock metadata, or modify lock state if write permissions are inherited.
    </Details>
    <Statement xml:lang="en:us">
This vulnerability is evaluated with Moderate severity because local accounts can delay lock acquisitions or inspect lock metadata, though the blast radius is strictly confined to Windows systems. Red Hat products operate in Linux environments where filelock applies standard POSIX file modes rather than Windows access control lists. Consequently, Red Hat enterprise deployments are not affected by this flaw.
    </Statement>
    <Mitigation xml:lang="en:us">
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
    </Mitigation>
    <PackageState cpe="cpe:/a:redhat:openshift_ai">
        <ProductName>Red Hat OpenShift AI (RHOAI)</ProductName>
        <FixState>Fix deferred</FixState>
        <PackageName>rhoai/odh-mlflow-rhel9</PackageName>
    </PackageState>
    <References xml:lang="en:us">
https://www.cve.org/CVERecord?id=CVE-2026-112910
https://nvd.nist.gov/vuln/detail/CVE-2026-112910
https://github.com/tox-dev/filelock/commit/72786d41aa25159ad28c1bcf4291738b135b2c6c
https://github.com/tox-dev/filelock/commit/e1e825b1992f69fb6b346dc395d5ae4893536c0a
https://github.com/tox-dev/filelock/pull/835
https://github.com/tox-dev/filelock/releases/tag/4.2.1
https://github.com/tox-dev/filelock/security/advisories/GHSA-8mx5-7m5m-r77g
    </References>
</Vulnerability>