On September 2023, a critical security flaw was found in the Jenkins Assembla Auth Plugin (up to version 1.14). This vulnerability, now tracked as CVE-2023-41945, impacts Jenkins servers that use the plugin to authenticate users. Simply put, the plugin fails to correctly check which permissions are allowed, resulting in users getting more access than they should—even if some permissions are completely disabled in the Jenkins security setup.

This post breaks down the bug, explains how the attack works with code samples, and shows simple ways to protect your setup.

Vulnerable versions: 1.14 and earlier

- Patched in: 1.15 (See Jenkins Security Advisory)

The Assembla Auth plugin helps Jenkins integrate with Assembla for user authentication. It maps Assembla permissions to Jenkins roles.

The Problem – Permissions Not Checked

When a user logs in, the plugin checks the permissions included in their Assembla account and grants those in Jenkins. The problem is, it does not check whether these permissions are actually enabled in Jenkins’ own configuration.

Result:
If a user has the “EDIT” permission, the plugin always grants them to Jenkins' “Overall/Manage” and “Overall/SystemRead” permissions—even if those permissions are supposed to be restricted in Jenkins.

Example Scenario

- Jenkins admin disables “Overall/Manage” for regular users.

User logs in via Assembla (with “EDIT”).

- User gets “Overall/Manage” and “Overall/SystemRead” anyway.

Let’s look at a simplified version of the (vulnerable) mapping logic inside the plugin

// Pseudo-code from the Assembla Auth plugin before fix
if(userHasAssemblaEdit()) {
    // plugin grants manage/systemread regardless of Jenkins' disable state
    grantPermission(OVERALL_MANAGE);
    grantPermission(OVERALL_SYSTEMREAD);
}

The plugin does not check

if(jenkins.isPermissionEnabled(OVERALL_MANAGE)) { ... }

This ignores Jenkins’ global permission settings!

Request Access: An attacker with an “EDIT” Assembla account logs into Jenkins.

2. Get Extra Rights: The Assembla Auth plugin maps their “EDIT” to Jenkins’ “Overall/Manage” and “Overall/SystemRead” without checking if these are disabled by Jenkins security.
3. Perform Admin Actions: The attacker can now perform administrative actions, such as reconfiguring jobs, reading full system state, or even enabling other plugins.

Suppose you have a Jenkins instance running at https://jenkins.example.com

import requests

# Cookie you get after authenticating via Assembla SSO
cookies = {
    'JSESSIONID': 'your-session-id',
}

url = 'https://jenkins.example.com/manage'

# Try to access the "Manage Jenkins" page
response = requests.get(url, cookies=cookies)

if response.status_code == 200 and 'Manage Jenkins' in response.text:
    print("Exploit succeeded! You have admin access.")
else:
    print("Exploit failed or already patched.")

If “Manage Jenkins” is accessible even though your Jenkins admin disabled it, you’ve hit this vulnerability.

Upgrade Assembla Auth Plugin to version 1.15 or later.

- Download: https://plugins.jenkins.io/assembla-auth/

References and Further Reading

- Jenkins Security Advisory (SECURITY-3241)
- Plugin Changelog: https://plugins.jenkins.io/assembla-auth/
- CVE Entry: https://nvd.nist.gov/vuln/detail/CVE-2023-41945

Conclusion

CVE-2023-41945 made it easy for regular Assembla users with “EDIT” permissions to get advanced Jenkins permissions, even when those are supposed to be disabled. The only way to stay safe is to upgrade the plugin and review your access control policies. Don’t let a simple plugin glitch put your CI/CD infrastructure at risk—patch today!


If you have questions or want a quick audit script, feel free to ask in the comments!


*This post is exclusive and written in simple language for easy understanding. Always consult official sources before patching production systems.*

Timeline

Published on: 09/06/2023 13:15:11 UTC
Last modified on: 09/11/2023 19:07:22 UTC