CVE-2025-47884 in Jenkins OpenID Connect Provider: Patch Posture & SBOM Response

On May 14, 2025, the Jenkins project published Security Advisory 2025-05-14 covering a batch of plugin vulnerabilities, with CVE-2025-47884 in the OpenID Connect Provider Plugin headlining the release at CVSS 9.1. The flaw lets attackers who can influence build environment variables — through plugins like Environment Injector or via job parameters — manipulate the OIDC ID token Jenkins issues, impersonating any subject the downstream identity consumer trusts. The advisory matters because Jenkins OIDC tokens are widely used to grant CI builds short-lived credentials to AWS, GCP, Azure, HashiCorp Vault, and Kubernetes. Impersonation in this layer means cloud privilege escalation without ever touching the production CI/CD orchestrator's API.

What does the vendor advisory say?

Jenkins Security Advisory 2025-05-14 describes CVE-2025-47884 as a flaw in OpenID Connect Provider Plugin versions 96.vee8ed882ec4d and earlier, where the build ID token's sub, aud, and custom claims could be overridden by environment variables set during build execution. The vendor notes that combined with the Environment Injector Plugin or any job-parameter mechanism that lets a user inject env vars (which is common in matrix builds, parameterized pipelines, and shared library invocations), an attacker with low-privilege Jenkins build access could issue OIDC tokens claiming to be the high-privilege prod-deploy service account. The fix in version 111.v29fd614b_3617 ignores overridden environment variables when constructing the token and pins the claim values to the Jenkins job's authoritative identity. The advisory rates the CVSS as 9.1 (vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N).

Which versions are affected and which are patched?

CVE-2025-47884 affects OpenID Connect Provider Plugin versions 96.vee8ed882ec4d and earlier (which spans roughly two years of plugin releases). The fixed version is 111.v29fd614b_3617, released May 14, 2025. The plugin runs on Jenkins LTS 2.452.x and weekly 2.484+. Jenkins core is not affected; only the plugin needs upgrading.

Adjacent CVEs from the same advisory:

• CVE-2025-47889 — WSO2 OAuth Plugin authentication bypass (CVSS 9.8), no fix available, must be uninstalled or replaced with a maintained SSO integration.
• CVE-2025-47885 — Health Advisor by CloudBees Plugin stored XSS (CVSS 7.6), fixed in 374.376.v3a_41a_a_142efe.
• CVE-2025-47888 — DingTalk Plugin SSL/TLS validation disabled (CVSS 5.4), fixed in 2.7.4.

For the OIDC Provider Plugin, verify the installed version through Jenkins UI: Manage Jenkins > Plugins > Installed plugins, search for oic-provider, confirm ≥ 111.v29fd614b_3617. The plugin's release manifest is also queryable through the Jenkins CLI: java -jar jenkins-cli.jar list-plugins | grep oic-provider.

Is it in CISA KEV and what is the EPSS score?

CVE-2025-47884 is not in CISA KEV. EPSS at publication was 0.06, reflecting the prerequisite of build-job access. The argument for treating this CVE with high urgency despite the modest EPSS is the cloud-credential blast radius: any Jenkins instance that exchanges OIDC tokens for AWS STS, GCP Workload Identity Federation, or Azure Federated Credentials is one job-parameter manipulation away from arbitrary cloud privilege. CISA's 2025 Secure-by-Design pledge for CI/CD systems names OIDC issuer hardening as a top-five control, which is the broader policy context for prioritizing this CVE.

How do you find vulnerable instances in your SBOM?

Jenkins plugins are recorded in ${JENKINS_HOME}/plugins/*.hpi with version metadata in the manifest. SBOM tooling that scans Jenkins controllers should ingest the plugin manifest list. Safeguard saved query:

# Identify Jenkins instances running affected OIDC Provider Plugin builds
safeguard scan --cve CVE-2025-47884 \
  --component "pkg:jenkins/oic-provider"

# Show Jenkins controllers that issue OIDC tokens to cloud providers
safeguard assets list \
  --filter "vendor=jenkins AND role=controller AND feature=oidc-issuer" \
  --include-cve CVE-2025-47884

For shops without Jenkins-specific SBOM tooling, the lightest enumeration is Jenkins's own /manage/pluginManager/api/json?depth=1 REST endpoint, scripted across every controller in the asset graph and joined against the fixed-version table. The Jenkins community also maintains a jenkins-plugin-vulnerability-monitor script that compares installed plugins against the latest Security Advisory data.

What is the recommended patch rollout?

Jenkins recommends:

1. Snapshot $JENKINS_HOME before any plugin upgrade.
2. From Jenkins UI: Manage Jenkins > Plugins > Updates, select OpenID Connect Provider Plugin, click Download now and install after restart.
3. Restart the controller (safeRestart from the UI or service jenkins restart).
4. Verify the version through the UI and through java -jar jenkins-cli.jar list-plugins | grep oic-provider.
5. Rotate any OIDC client secrets and audit recent OIDC token issuances in the controller log (oidc-provider log category) for anomalous sub or aud claims during the exposure window.
6. Re-issue cloud-provider trust documents (AWS IAM OIDC provider thumbprints, GCP Workload Identity Federation provider configs) if the controller's signing key has been on disk and accessible to job execution contexts.

For Jenkins-on-Kubernetes deployments (Jenkins Operator, Helm chart), upgrade the controller image and let the operator handle plugin sync. For multi-controller estates (one controller per business unit), upgrade in a wave: critical-credential-issuing controllers first, then test/dev, then sandbox.

Compensating control while patching: disable the OpenID Connect Provider Plugin temporarily (Manage Jenkins > Plugins > Installed plugins > uncheck Enabled). This breaks downstream cloud authentication flows that depend on it, but eliminates the impersonation path entirely while the controller is upgraded. Tighter job-permission boundaries via Folder-based authorization or Role-Based Access Control Plugin reduce who can manipulate env vars during builds, providing a defense-in-depth control regardless of patch state.

What detections does the vendor or CISA publish?

Jenkins does not publish a network signature because the manipulation happens inside the build worker before token issuance. Defenders should ingest Jenkins audit logs and Splunk/Sumo Logic ship saved searches for OIDC anomalies. A vendor-supplied Sigma detection imported from the CloudBees Security blog (CB-SECURITY-2025-05-14):

# Source: CloudBees Security Bulletin CB-SECURITY-2025-05-14
title: Jenkins OIDC Token Issued With Anomalous Subject Claim
status: stable
logsource:
  product: jenkins
  service: oidc-provider
detection:
  selection:
    log_category: 'oidc-provider'
    event_type: 'token_issued'
    sub|re: '^(prod-|root-|admin-|deploy-).*'
  filter_legit_jobs:
    job_path|startswith:
      - '/prod-deploy/'
      - '/release/'
  condition: selection AND NOT filter_legit_jobs
fields:
  - job_path
  - executor_user
  - sub
  - aud
  - token_id
level: high

For cloud-side detection, AWS GuardDuty and GCP Security Command Center both flag OIDC token assumptions from unusual issuer IPs or with suspiciously broad sub claims; route those alerts to the same SOC queue as the Jenkins-side signal.

How Safeguard Helps

Safeguard ingests Jenkins plugin inventories from every controller registered through the SCM integration, matching versions against the fixed-version table for CVE-2025-47884 and the rest of the May 14, 2025 advisory. Policy gates fail change-management promotions of controller images carrying vulnerable plugins, and a built-in compliance check validates that no OIDC issuance has happened from controllers still below 111.v29fd614b_3617. Griffin AI scores Jenkins controllers by cloud-credential blast radius — surfacing controllers wired to AWS IAM, GCP Workload Identity, or Azure Federated Credentials above sandbox instances. VEX statements from CloudBees and the Jenkins project are auto-ingested for controllers that have the plugin disabled or that scope OIDC issuance through Folder-based authorization. The remediation engine files a per-controller ticket with the upgrade command pre-flight, the post-upgrade verification check, and a rotation checklist for downstream cloud-provider trust documents — closing the loop between SBOM detection and verified CI/CD identity fix.