Security Advisory: SonarQube Scanner GitHub Action

Sonar Updates
1

Update 9/25/2025: Please read this follow-up post:

Hi all,

We’ve found a security vulnerability in our SonarQube Scanner GitHub Action, and we’ve already released a patch to fix it.

What You Need to Do

Please update your SonarQube Scanner GitHub Action to v5.3.1. This new version is applicable for both Cloud and Server customers and includes a security fix that will help protect your workflows. If your workflow uses dynamically computed arguments, you will additionally need to switch to using supported syntax for expressions in GitHub Actions.

If your workflow references sonarqube-scan-action@v5, it will automatically use the patched version, and no further action is required.

Update (September 2, 2025):

See the latest information here:

2

Is the Azure DevOps extension for SonarQube Cloud affected by this vulnerability as well? If so, what version should AzDO users upgrade to?

Thanks!

1 Like
3

Is this limited to the GitHub action and therefore our scans using the maven scanner are not impacted?

4

Hi all,

This is just about the GitHub Action. Your use of any other SonarScanner is not impacted. Altho we do generally recommend you try to stay on the latest version of your scanner, there are no known security impacts for any other scanner at this time.

 
HTH,
Ann

5

Can you share anything about what the vulnerability was? Or at the very least, if it was exploited, what we should be looking for?

2 Likes
6

Hi,

We’re not aware of any exploits. And again

 
HTH,
Ann

7

We are using SonarCloud, linking our project with GitHub directly, but we have not written or configured any .yml file for GitHub Actions (i.e., we are not actively using the SonarQube Scanner GitHub Action in our workflow). Could you please confirm whether this vulnerability impacts SonarCloud users in our situation?

8

Hi @Jagrit,

Welcome to the community!

This only impacts the use of the SonarScanner GitHub Action.

Again,

 
HTH,
Ann

1 Like
9

Could you please provide the following critical details:

  1. Severity Level: What is the CVSS score or severity rating of this vulnerability?

  2. Attack Vector & Exploitability:

    • Is this remotely exploitable?

    • Does it require authentication?

    • What level of access could an attacker gain?

  3. Specific Impact:

    • What exactly is vulnerable?

    • Could this expose secrets, environment variables, or repository contents?

    • Are build artifacts at risk?

  4. Affected Versions: Which versions prior to v5.3.1 are affected?

  5. How would we know if this vulnerability has been exploited in our workflows?

  6. Timeline: When was this vulnerability discovered and how long have affected versions been in use?

While you mention “no evidence of exploitation,” understanding the actual risk profile would help us prioritize this update appropriately, especially heading into a weekend.

5 Likes
10

Exactly. Given the complete lack of transparency here, I’m not at all reassured by the fact that Sonar has no evidence that this vulnerability, whatever it is, was not exploited. I need to know whether I should be spending my weekend rotating secrets or whether this is a nothing burger. What a horrible way to announce this, and on a (US) holiday weekend no less.

2 Likes
11

Hi all,

Thanks for your candid feedback, and sorry for the mystery. We’ve begun the process to file the CVE, and will report back as soon as we have a number. Unfortunately, we won’t be able to share anything more until we have that.

In the meantime - and without prematurely releasing sensitive details so that everyone has an opportunity to do the update - we can say we believe this is “high” severity. Versions since v4.0.0 are impacted.

(And we’ll be taking the learnings from this on board in our retrospective. They’ll definitely impact our operations going forward.)

 
Ann

12

What does this mean? I am aware of GiHub Actions’ expressions syntax, but what are “dynamically computed arguments” in this context? The two don’t seem mutually exclusive to me, so what does it mean to be switching from one to the other? Can you at least provide some simple example of needed change? That would help a lot.

Thanks!

13

Ok, I figured out that you mean the args input on the Sonar action.

Needing to change, for example, from:

--define sonar.cfamily.compile-commands="$RUNNER_TEMP/sonar/compile_commands.json"

to

--define sonar.cfamily.compile-commands=${{ runner.temp }}/sonar/compile_commands.json

Presumably because environment variables are no longer be expanded within the Action’s handling of args.

That’s fine for me, in this case, but I will just note that expanding GitHub context variables this way does not perform any shell parameter escaping, so it would fail with spaces in paths, for example.

14

You should also release an update for the deprecated SonarSource/sonarcloud-github-action. Currently it still delegates to a vulnerable version of SonarSource/sonarqube-scan-action inside its action.yml:

    - name: SonarQube Cloud Scan
      uses: SonarSource/sonarqube-scan-action@v5.0.0
      with:
        args: ${{ inputs.args }}
        projectBaseDir: ${{ inputs.projectBaseDir }}
        scannerVersion: ${{ inputs.scannerVersion }}
        scannerBinariesUrl: ${{ inputs.scannerBinariesUrl }}
15

Unfortunately, we won’t be able to share anything more until we have that.

In the meantime - and without prematurely releasing sensitive details so that everyone has an opportunity to do the update - we can say we believe this is “high” severity. Versions since v4.0.0 are impacted.

Just as a side note: The code of the SonarSource/sonarqube-scan-action and the changes on it are public, so anyone can lookup how the vulnerability was fixed, and from there figure out how the previous versions can be exploited. So you should assume that the knowledge of how to exploit it is aleady out there.

6 Likes
16

+1; withholding further information at this point is just a form of security through obscurity (i.e. ineffective) and prevents those of us who are affected from properly assessing the level of risk and impact without taking Sonar’s word for it.

Respectfully, I strongly encourage the Sonar team to not wait for a retrospective before enacting changes - this current situation easily be improved with simple disclosure like was suggested above.

3 Likes
17

We are using “sonarsource/sonarqube-scan-action@master” this automatically take the latest version?

18

IMHO there is no point in not disclosing this right away when it’s already in plain sight:

There are even test cases in the repo that show exactly how to exploit the vulnerability: a potential command injection caused by unsanitized arguments.

Since this is an open-source repository, a bad actor could figure out the vulnerability in minutes. In this case, withholding information does more harm than good by not being completely transparent with customers from the start.

4 Likes
19

Yes, @master takes the latest commit, which includes the fix. And, we generally recommend not pinning to master, since there might eventually be a breaking change. I’d reccomend using @5.

20

Hey everyone,

A few updates:

First of all, thank you to everyone who provided feedback on our communication. We’re taking your feedback seriously and will be reviewing our vulnerability disclosure procedures and policies.

Secondly, we now have additional details to share:

CVE Number: CVE-2025-58178 has been assigned to this vulnerability

Vulnerability Type: Command Injection via unsanitized arguments

CVSS v3.1 Score: 7.8

GitHub Security Advisory: We’ve published a GitHub Security Advisory which means Dependabot users will automatically receive alerts and pull requests to update

Affected Versions: All versions from v4.0.0 up to v5.3.0

Action Required:

  • Update to v5.3.1 (fixed version)
  • If using sonarqube-scan-action@v5, you’re already receiving the patched version automatically
  • For those using dynamically computed arguments in the args field of sonarqube-scan-action, please update to use GitHub Actions expression syntax
1 Like