CVE-2026-114608 in Pylint
Summary
by MITRE • 10/23/2026
Pylint is a static code analyser for Python. From 0.15.2 until 4.0.9, Pylint stores module statistics in predictable files under PYLINT_HOME and loads those files with pickle.load on a later run. An attacker who can write to a shared, group-writable, or otherwise untrusted cache directory can replace a stats cache with crafted serialized data, causing arbitrary code to execute with the privileges of the user who next runs Pylint. The default per-user cache is not normally writable by another user. This issue is fixed in version 4.0.9.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified involves a critical insecure deserialization flaw within Pylint, a widely used static code analysis tool for the Python programming language. Operating under versions ranging from 0.15.2 through 4.0.9, the software exhibits a dangerous design pattern where it persists module statistics and other internal data into files located in directories defined by the PYLINT_HOME environment variable or default cache locations. The core technical deficiency lies in the method used to serialize and deserialize this state information. Specifically, Pylint utilizes Python's pickle module for both storing these statistical caches during execution and loading them back on subsequent runs. While pickling is a convenient mechanism for serializing complex Python objects, it inherently poses significant security risks because the deserialization process can execute arbitrary code contained within the serialized payload if an attacker gains control over the input data stream.
The operational impact of this vulnerability stems from the predictability and accessibility of the cache files. Pylint stores these statistics in predictable file paths, which allows for targeted manipulation by malicious actors. If a user configures their environment to use a shared directory, such as /tmp or a group-writable project folder, or if they explicitly set PYLINT_HOME to an untrusted location, the security boundary is effectively neutralized. An attacker with write access to this specific cache directory can replace the legitimate statistics file with a maliciously crafted serialized object. When another user subsequently runs Pylint in that environment, the tool will automatically load and deserialize the tampered data without any verification or sanitization steps. This process results in the immediate execution of arbitrary code embedded within the pickle payload, running with the full privileges of the victim user who invoked the linter.
This flaw is classified under CWE-502, which denotes Deserialization of Untrusted Data, a category of vulnerabilities where an application deserializes untrusted data without sufficiently verifying that the resulting data will be valid. In terms of offensive security frameworks, this vulnerability aligns with MITRE ATT&CK technique T1059, specifically sub-technique 006 for Command and Scripting Interpreter: Python, as it allows for remote code execution via a scripting language interpreter triggered by standard tool usage. The severity is further compounded by the fact that static analysis tools are often run frequently during development cycles, increasing the likelihood of exposure in collaborative environments where shared directories or CI/CD pipelines might inadvertently expose these cache files to other processes or users with lower privilege levels but write access to temporary storage areas.
Mitigation strategies primarily involve upgrading to version 4.0.9 or later, where this insecure deserialization pattern has been addressed by the developers through safer serialization methods or strict input validation. For environments that cannot immediately upgrade, administrators should ensure that PYLINT_HOME is set to a directory with restrictive permissions, ensuring it is not group-writable and accessible only to the specific user running Pylint. Additionally, avoiding the use of shared temporary directories for cache storage can significantly reduce the attack surface. It is also advisable to audit CI/CD pipelines and development workflows to ensure that no untrusted users or services have write access to any directory designated for tool caches, thereby preventing the initial file replacement step required to exploit this vulnerability.