Curseforge Publisher
Monthly
Information disclosure in the Jenkins Curseforge Publisher Plugin 1.0 causes the stored CurseForge API key to be rendered unmasked (in cleartext) on the plugin's job configuration form, so any user who can reach that form can read the credential. According to the CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), exploitation requires an authenticated Jenkins user with at least the privileges needed to view the job configuration, and impact is limited to confidentiality - no integrity or availability effect - although downstream risk depends on what the leaked CurseForge API key is authorized to do. There is no public exploit identified at time of analysis, EPSS is low at 0.26% (16th percentile), and the root cause is CWE-311 (missing protection/masking of sensitive data) in version 1.0 of this specific plugin, not in Jenkins core. This is a low-to-moderate severity credential-exposure issue rather than a high-priority emergency, and it also exposes the key to anyone able to observe the configuring user's screen.
Cleartext storage of CurseForge API keys in Jenkins Curseforge Publisher Plugin 1.0 writes the secret in plaintext into each configured job's config.xml on the Jenkins controller, allowing users who hold Item/Extended Read permission on that job - or anyone with read access to the controller filesystem - to retrieve the key. The issue is remote and network-reachable but requires low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, score 4.3), is an information-disclosure-only condition with no code execution or integrity/availability impact, and there is no public exploit identified at time of analysis and no confirmed active exploitation (EPSS 0.17%, 6th percentile). Realistic exposure is limited to the confidentiality of the CurseForge API key and whatever that key authorizes on CurseForge, and only when a key has actually been configured in a job.
Information disclosure in the Jenkins Curseforge Publisher Plugin 1.0 causes the stored CurseForge API key to be rendered unmasked (in cleartext) on the plugin's job configuration form, so any user who can reach that form can read the credential. According to the CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), exploitation requires an authenticated Jenkins user with at least the privileges needed to view the job configuration, and impact is limited to confidentiality - no integrity or availability effect - although downstream risk depends on what the leaked CurseForge API key is authorized to do. There is no public exploit identified at time of analysis, EPSS is low at 0.26% (16th percentile), and the root cause is CWE-311 (missing protection/masking of sensitive data) in version 1.0 of this specific plugin, not in Jenkins core. This is a low-to-moderate severity credential-exposure issue rather than a high-priority emergency, and it also exposes the key to anyone able to observe the configuring user's screen.
Cleartext storage of CurseForge API keys in Jenkins Curseforge Publisher Plugin 1.0 writes the secret in plaintext into each configured job's config.xml on the Jenkins controller, allowing users who hold Item/Extended Read permission on that job - or anyone with read access to the controller filesystem - to retrieve the key. The issue is remote and network-reachable but requires low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, score 4.3), is an information-disclosure-only condition with no code execution or integrity/availability impact, and there is no public exploit identified at time of analysis and no confirmed active exploitation (EPSS 0.17%, 6th percentile). Realistic exposure is limited to the confidentiality of the CurseForge API key and whatever that key authorizes on CurseForge, and only when a key has actually been configured in a job.