CVE-2024-52549

What it actually does

The flaw is an improper permission check in Jenkins Script Security Plugin form validation logic. In affected versions, a user with only Overall/Read permission can invoke a validation method that should require Overall/Administer and use it to test whether arbitrary paths exist on the Jenkins controller filesystem. The issue is an information disclosure/access-control bypass: it does not directly read file contents, write files, or execute code, but it can reveal the presence of sensitive files, Jenkins home paths, plugin artifacts, secrets-related files, or operating system paths that support follow-on attacks.

Why it matters to the business

Organizations running affected Jenkins controllers may expose internal filesystem information to low-privileged users, or to unauthenticated users if anonymous Overall/Read access is enabled. While the CVSS score is moderate and EPSS is low, the issue has been public for a long period and should be treated as overdue maintenance on internet-accessible or broadly shared Jenkins instances. Successful abuse can help attackers profile Jenkins installations, confirm where secrets or configuration files are located, and make later credential theft, social engineering, or chained exploitation more effective.

How an attack unfolds

An attacker first obtains access to Jenkins with Overall/Read permission, or targets a Jenkins instance where anonymous users have Overall/Read. The attacker then sends crafted HTTP requests to the Script Security Plugin form validation endpoint and supplies candidate controller-side file paths. The vulnerable plugin performs the filesystem existence check without requiring administrator permission and returns a response that differs depending on whether the path exists. By repeating requests with common Linux, Windows, container, and Jenkins home paths, the attacker builds an inventory of the controller filesystem layout and sensitive file locations. The attacker can then use this knowledge to guide additional attacks, such as targeting known Jenkins secret files, validating backup locations, identifying plugin or installation paths, or preparing more precise exploitation of other Jenkins weaknesses.

How to fix it

Upgrade Jenkins Script Security Plugin to 1368.vb_b_402e3547e7 or later. The advisory also notes that 1365.1367.va_3b_b_89f8a_95b_ and 1362.1364.v4cf2dc5d8776 are exceptions to the affected range. For source-based tracking, the Jenkins plugin repository fix is associated with commit 4cf2dc5d8776b119e25d203abbe695fc618c5129. After upgrading, restart Jenkins if required and verify the active plugin version from the Jenkins plugin manager or plugin manifest. As compensating controls, remove anonymous Overall/Read access, minimize low-privileged user access to Jenkins, restrict controller exposure to trusted networks or SSO/VPN boundaries, and ensure authorization strategy settings do not grant broad read access unnecessarily. If asset inventories also flag Ubuntu libbluray 16.04 under this CVE mapping, apply the vendor fixed package 1:0.9.2-2 and validate the mapping against vendor advisories; the described vulnerability is in Jenkins Script Security Plugin.

How to confirm the fix worked

Confirm that every Jenkins controller has Script Security Plugin 1368.vb_b_402e3547e7 or later, or one of the explicitly non-affected exception builds. Validate through Manage Jenkins > Plugins, plugin manager CLI output, or the META-INF/MANIFEST.MF version in the installed script-security plugin file. Perform a permission test with a non-admin account that has only Overall/Read: requests to the affected form validation function should be denied or should not disclose whether controller filesystem paths exist. Also confirm anonymous users do not have Overall/Read unless intentionally required. Review reverse proxy, Jenkins access, and audit logs after patching to ensure no continued successful probing of the form validation endpoint by non-admin users.

Typical attack path

1. Identify a Jenkins controller running an affected Script Security Plugin version.
2. Authenticate as a low-privileged user with Overall/Read permission, or use anonymous access where Overall/Read is enabled.
3. Send crafted requests to the affected Script Security Plugin form validation method with a filesystem path parameter.
4. Compare HTTP status codes, response bodies, or validation messages to determine whether each tested path exists on the controller.
5. Enumerate common Jenkins, operating system, container, and secrets-related paths.
6. Use the discovered filesystem information to support follow-on reconnaissance, credential-targeting, or chained exploitation.

How to detect it

Look for evidence of path-probing against Jenkins form validation endpoints. Primary log sources are Jenkins access logs, Winstone logs, reverse proxy logs such as NGINX or Apache, WAF logs, load balancer logs, Jenkins audit trail plugin logs if enabled, and identity provider sign-in logs for the associated Jenkins users. Focus on requests to descriptorByName or form validation URLs associated with the Script Security Plugin, especially requests containing file: URLs, absolute filesystem paths, Windows drive letters, Jenkins home directories, secrets/master.key, credentials.xml, config.xml, or plugin paths. Suspicious behavior often appears as repeated GET or POST requests with small variations in a path parameter and responses that differ between existing and non-existing paths. Correlate the source IP, authenticated Jenkins user, session cookie, user agent, and API token activity with later Jenkins actions such as job configuration reads, credential enumeration attempts, script approval views, build log access, or administrative page access. Because this vulnerability does not create files or spawn processes by itself, absence of host artifacts does not rule out exploitation; web and audit logs are the best evidence source.

• /descriptorByName/org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.ClasspathEntry/checkPath
• org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.ClasspathEntry/checkPath
• descriptorByName/org.jenkinsci.plugins.scriptsecurity
• checkPath?value=file:
• value=file:/etc/passwd
• value=file:/etc/shadow
• value=file:/var/lib/jenkins/secrets/master.key
• value=file:/var/jenkins_home/secrets/master.key
• value=file:/var/lib/jenkins/credentials.xml
• value=file:/var/jenkins_home/credentials.xml
• value=file:/var/lib/jenkins/config.xml
• value=file:/var/jenkins_home/config.xml
• value=file:/var/lib/jenkins/plugins/
• value=file:/var/jenkins_home/plugins/
• value=file:C:\Windows\win.ini
• value=file:C:\ProgramData\Jenkins\.jenkins\secrets\master.key
• value=file:C:\ProgramData\Jenkins\.jenkins\credentials.xml
• secrets/master.key
• credentials.xml

What your security team should do

• Prioritize upgrade of Jenkins Script Security Plugin to 1368.vb_b_402e3547e7 or later on all controllers, especially internet-facing or shared CI/CD instances.
• Audit Jenkins authorization settings and remove anonymous Overall/Read and unnecessary low-privileged read access.
• Search historical Jenkins, reverse proxy, WAF, and audit logs for suspicious form validation requests containing controller filesystem paths.
• Treat confirmed probing of Jenkins secrets, credentials, or master.key paths as potential reconnaissance and investigate the associated user account, session, API token, source IP, and subsequent activity.
• Add SIEM detections for Script Security Plugin form validation requests containing file: URLs, absolute Unix paths, Windows drive paths, or Jenkins secrets-related filenames.
• Where exposure is found, rotate Jenkins user API tokens or credentials only if additional evidence suggests follow-on access or credential compromise; this CVE alone discloses existence, not file contents.
• Include Jenkins plugin versions in continuous vulnerability management so security plugin updates are not missed.