CVE-2026-27100

What it actually does

Jenkins versions 2.550 and earlier and LTS 2.541.1 and earlier fail to enforce authorization correctly when processing Run Parameter values submitted to a parameterized build. An authenticated user with Item/Build and Item/Configure permissions on a job can submit Run Parameter values that reference jobs or builds they are not otherwise permitted to view. Jenkins may then reveal whether the referenced job exists, whether a specific build exists, and, when it exists, the build display name. The impact is limited to unauthorized information disclosure; the vulnerability does not directly allow code execution, build modification, privilege escalation, or denial of service.

Why it matters to the business

This issue can expose sensitive CI/CD metadata such as hidden job names, release or deployment build identifiers, branch or environment naming, and build display names. While the CVSS score is moderate and EPSS is currently low, Jenkins often contains operationally sensitive information about applications, deployments, and internal project structure, so the leaked metadata may help an attacker map the software delivery environment for follow-on attacks. It is not listed in CISA KEV and there is no indication from the provided data that it is being used in ransomware campaigns, which lowers immediate emergency priority but does not remove the need to patch internet-accessible or multi-tenant Jenkins controllers.

How an attack unfolds

An attacker first needs a valid Jenkins account that can configure and build at least one job. They configure or use a parameterized job with a Run Parameter, then submit build requests containing crafted Run Parameter values that reference other Jenkins jobs and build numbers outside their authorization scope. Because vulnerable Jenkins versions accept these references before performing the necessary access check, the attacker can compare responses, validation behavior, build parameter handling, console output, queue behavior, or related UI/API responses to infer whether the target job exists and whether a specific build number exists. If a referenced build exists, Jenkins may disclose its display name. The attacker can repeat this process across guessed job paths and build numbers to enumerate hidden pipelines and gather operational context for later phishing, credential targeting, source-code reconnaissance, or CI/CD abuse.

How to fix it

Upgrade Jenkins to a fixed version: Jenkins weekly 2.551 or later, Jenkins LTS 2.541.2 or later, or a build that includes the upstream fix commit fc71f0677ff81340ba7eb19b2d571fb9af230437. If immediate upgrade is not possible, reduce exposure by reviewing and limiting Item/Configure and Item/Build permissions, especially for untrusted or broadly assigned users; remove unnecessary Run Parameters from jobs; restrict who can configure parameterized jobs; disable anonymous access; and place Jenkins behind SSO/VPN or other access controls where appropriate. Treat these mitigations as temporary because the underlying authorization bypass is corrected only by upgrading.

How to confirm the fix worked

Confirm the running Jenkins version is newer than the affected ranges: greater than 2.550 for weekly releases or greater than LTS 2.541.1 for LTS releases. For source or custom builds, confirm the deployed code includes commit fc71f0677ff81340ba7eb19b2d571fb9af230437. Review job configurations for Run Parameter usage and verify that users with Item/Build and Item/Configure on one job cannot submit Run Parameter values that reference inaccessible jobs or builds. A practical validation test is to use a low-privileged test account, configure or trigger a job with a Run Parameter, submit references to a job/build the account cannot view, and confirm Jenkins does not reveal job existence, build existence, or build display names. Also verify permissions using Jenkins' matrix authorization or role strategy configuration to ensure Item/Configure is not granted more broadly than intended.

Typical attack path

1. Obtain authenticated access to Jenkins with Item/Build and Item/Configure permissions on at least one job.
2. Create or modify a parameterized job that uses a Run Parameter, or identify an existing job with such a parameter.
3. Submit builds through the Jenkins UI, CLI, or HTTP endpoint with Run Parameter values referencing guessed job names and build numbers that the attacker cannot normally access.
4. Observe differences in Jenkins responses, validation results, queue/build behavior, API output, or console output to determine whether referenced jobs and builds exist.
5. Collect exposed build display names and use the metadata to map projects, release processes, environments, or deployment activity.
6. Use the reconnaissance to support follow-on attacks against CI/CD credentials, source repositories, deployment pipelines, or personnel.

How to detect it

Look for signs of authenticated reconnaissance rather than malware or direct compromise. Relevant sources include Jenkins HTTP access logs, reverse proxy or load balancer logs, Jenkins audit logs, Audit Trail plugin output if enabled, job configuration history, build queue records, and build logs for parameterized jobs. Focus on users who have Item/Build and Item/Configure but are not administrators. Hunt for creation or modification of jobs that add Run Parameters, followed by repeated build submissions using buildWithParameters or similar endpoints. Pay attention to requests containing parameter values that look like Jenkins job paths, encoded nested job paths, or many sequential build numbers. Compare requested job/build references against the requesting user's normal authorization scope. If logs show repeated probing of inaccessible job paths or build numbers, treat it as potential exploitation. Because the flaw leaks metadata through normal Jenkins request/response behavior, there may be no unique exploit string; detection depends on correlation of parameterized build submissions, Run Parameter use, permission boundaries, and unusual enumeration patterns.

• /buildWithParameters
• POST /job/
• GET /job/
• /job/.*/buildWithParameters
• RunParameterDefinition
• hudson.model.RunParameterDefinition
• <hudson.model.RunParameterDefinition>
• </hudson.model.RunParameterDefinition>
• job=
• %2Fjob%2F
• ../job/
• /queue/item/
• config.xml

What your security team should do

• Patch Jenkins controllers to 2.551 or later, LTS 2.541.2 or later, or a build containing commit fc71f0677ff81340ba7eb19b2d571fb9af230437.
• Prioritize internet-accessible Jenkins instances, shared CI/CD platforms, and environments with many project teams or delegated job configuration rights.
• Inventory jobs using Run Parameters and review whether those parameters are still required.
• Audit users and groups with both Item/Build and Item/Configure permissions; remove broad configure rights from non-administrative users where possible.
• Review Jenkins access logs, audit logs, and job configuration history for unusual creation or modification of parameterized jobs followed by repeated build submissions.
• Monitor for repeated buildWithParameters requests, especially requests containing encoded job paths, unusual build-number probing, or activity from users with limited project scope.
• If suspicious enumeration is found, review what job and build metadata may have been exposed and assess whether follow-on credential, repository, or deployment pipeline activity occurred.