Bug 2556198 (CVE-2026-112909)

Summary:	CVE-2026-112909 filelock: filelock: arbitrary file truncation via lock path replacement
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	akhatavk, alinfoot, anpicker, anthomas, aos-team-art-private, aprice, asdas, bbrownin, blitton, cahl, cmyers, dfreiber, dnakabaa, dpaolell, drow, dschmidt, dtrifiro, ebourniv, ehelms, gbenhaim, ggainey, hasun, hoberger, ilpinto, jburrell, jdelft, jdobes, jfula, jholecek, jlanda, jmitchel, jowilson, jpasqual, jsamir, jupierce, juwatts, jwong, kaycoth, kgaikwad, kshier, lcouzens, lgarciaa, ljawale, lpele, ltomasbo, mbarnett, mbiarnes, mdellweg, mhayden, mhulan, msilmser, mwoodson, niyer, nmoumoul, nyancey, oezr, omaciel, ometelka, orabin, osousa, pcreech, ppalepu, ppostler, prdhamdh, prwatson, ptisnovs, rbobbitt, rchan, sarad, sbunciak, sdawley, sdoran, sghai, sidsharm, simaishi, smallamp, sprizend, stcannon, suppawar, syedriko, tmalecek, twaugh, vkumar, vlaad, weaton, xdharmai, yguenane, ykashtan, zzhou
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in filelock. A local attacker can exploit this vulnerability by placing a target regular file at the expected lock file path using a file rename or hard link. When filelock acquires the lock, it can unintentionally truncate the contents of the target file and alter its permissions, resulting in data loss.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-20 14:33:19 UTC

filelock is a platform-independent file lock for Python. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file's mode. This issue is fixed in version 4.2.1.