If you’re using GitLab’s DAST (Dynamic Application Security Testing) API Scanner—especially if your version falls between 1.6.50 and before 2.11.—you need to read this. A critical bug, tracked as CVE-2023-0326, was found that could expose your *Authorization headers* in vulnerability report evidence. In this post, I’ll walk you through what happened, why it matters, how it works, and what you should do next. Let’s break it down in plain English.

What is GitLab DAST API Scanner?

DAST API Scanner is a tool included with GitLab to help you find vulnerabilities in your web APIs by running automated security tests. It sends requests, receives responses, and reports possible security problems.

The Issue: How Were Authorization Headers Leaked?

Starting from version 1.6.50 all the way up to (but not including) 2.11., the scanner sometimes collected *sensitive* request and response information—which could include HTTP Authorization headers. These headers typically carry API tokens, JWTs, or other secrets that should remain private.

Here’s the kicker: this sensitive info was included in the scanner’s vulnerability report evidence. If your report wound up in the wrong hands, anyone with access to the evidence could see those secrets. This bug could expose API keys, user credentials, or even full access tokens.

The Code Behind the Problem

The vulnerable code essentially failed to scrub/omit the Authorization header from stored evidence, like the following simplified Python example:

def log_api_request(request):
    # Vulnerable code: leaks Authorization headers in logs/reports
    evidence = {
        "method": request.method,
        "url": request.url,
        "headers": dict(request.headers),  # includes Authorization
        "body": request.body
    }
    save_evidence_to_report(evidence)

A secure version should remove sensitive fields before storing

def log_api_request(request):
    headers = dict(request.headers)
    headers.pop("Authorization", None)  # Remove Authorization

    evidence = {
        "method": request.method,
        "url": request.url,
        "headers": headers,
        "body": request.body
    }
    save_evidence_to_report(evidence)

Run DAST scan against an API with Authorization headers.

2. Scanner logs/networks evidence including these headers.

Download or view the vulnerability report.

4. Look for stored request/response evidence—if you see an Authorization header or token, the bug is present.

Anyone with access to these reports can steal those headers and use them to access your APIs.

There’s no need to “hack” in the traditional sense—just access to DAST reports with evidence is enough.

If you’re wondering what the exposed section in a report _could_ look like, here’s an example

// (From a vulnerable report evidence)
{
    "method": "GET",
    "url": "https://api.example.com/user/profile";,
    "headers": {
        "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cC..."
    }
}

Official References

- GitLab Security Advisory for CVE-2023-0326
- GitLab Issue Tracker Details
- NIST NVD Entry CVE-2023-0326

How To Protect Yourself

- Update Immediately: Upgrade your GitLab DAST API scanner to *at least* version 2.11.. Get the latest here.
- Audit Old Reports: Manually check previous DAST reports for leaked tokens or secrets. Rotate any credentials found.

Restrict Report Access: Limit who can view or download security scanning reports.

- Review Scanner Configs: Always review what information your security tools are allowed to store and share.

Final Thoughts

This bug is a good reminder: security tools can *also* cause security issues if not properly handled. Always keep them updated, audit outputs for sensitive data, and restrict access to security reports. If your API scanner versions falls in the affected range, patch it now and check your old scan logs for exposed secrets.


Stay secure, and always treat your tools like another potential threat vector—not just your defenders!


> Need help or want to discuss this CVE further? Check out GitLab’s official discussion board!

Timeline

Published on: 03/27/2023 22:15:00 UTC
Last modified on: 04/03/2023 18:04:00 UTC