Tox-Dev
Vulnerability activity for Tox-Dev: what is being exploited, what was published lately, and when the next patch release is due.
Last 30 days
- CVEs
- 4
- Critical (CVSS 9+)
- 0
- Exploited (CISA KEV)
- 0
- With exploit code
- 0
Last 90 days
- CVEs
- 4
- Critical (CVSS 9+)
- 0
- Exploited (CISA KEV)
- 0
- With exploit code
- 0
Last 365 days
- CVEs
- 4
- Critical (CVSS 9+)
- 0
- Exploited (CISA KEV)
- 0
- With exploit code
- 0
Exploited now
None of this vendor's CVEs are on CISA's known-exploited list.
Recent
- 3.3LowOct 20, 2026Tox-Dev filelockCVE-2026-112941`SoftReadWriteLock` (and `AsyncSoftReadWriteLock`, which wraps one) checks once per lock object, by name, that `<path>.rw`, `<path>.rw/gen` and `<path>.rw/holders` are real directories and not symbolic links (files that redirect to another path). It then keeps only a boolean. Every later record operation resolves the full path again, and `O_NOFOLLOW` (a flag that makes an open fail when the final name is a symbolic link) protects the last component only. Another local user (the other user below)
- 4.7MediumOct 20, 2026Tox-Dev filelockCVE-2026-112935The stale-lock break shared by `SoftFileLock`, `MarkerSoftFileLock` and `SoftFileLease` (and their async variants, and a `FileLock` that has fallen back to a soft lock on `ENOSYS`, the "not implemented" error) recognises the marker it judged stale by two values. The marker is the lock file at `<path>`, whose presence says a process holds the lock. The values are its inode number (the kernel's identity for a file, independent of its name) and its modification time (mtime) not being newer. The che
- 6.3MediumOct 20, 2026Tox-Dev filelockCVE-2026-112911`StrictSoftFileLock`, `AsyncStrictSoftFileLock`, `SoftReadWriteLock` and `AsyncSoftReadWriteLock` keep their whole ownership state as files in a directory derived from the lock path (`<path>.filelock/claims`, `<path>.rw/{gen,holders}`). When that directory already exists they adopt it after checking only that it is a real directory, not who owns it. Another local user who can create names in the lock's directory can create the tree before the first acquire on that path by the user running the lo
- 6.1MediumOct 20, 2026Tox-Dev filelockCVE-2026-112909`UnixFileLock`, the backend of `FileLock` and `AsyncFileLock` on Unix, empties whatever regular file it finds at the lock path once it holds the `flock` (a kernel lock on an open file). With an explicit `mode` it also chmods that file (sets its permission bits), whether or not this acquire created it. Another local user who can rename or hard-link one of the files of the user running the lock (below: the lock user) onto the lock path gets that file truncated by the lock user's next `acquire()`.
Top products
- filelock4 CVEs in the last year
Counts cover CVEs and advisories Watch Floor tracks, by the date they became news. Updated every 10 minutes.