Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍 PyPI

GHSA-mqpq-2p68-46fv

HIGH

pyload Unauthenticated Flask Configuration Leakage vulnerability

Also known asCVE-2024-21644
Published
Jan 8, 2024
Updated
Feb 16, 2024
Affected
1 pkg
Patched
1 / 1
Exploits
1 known

EPSS Exploitation Probability

via FIRST.org ↗
42.2%probability of exploitation in next 30 days
High Risk99th percentile-44.33%
28.5%52.4%76.2%100.0%87.6%42.2%Dec 25Apr 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

1 pkg affected
🐍pyload-ng

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Summary

Any unauthenticated user can browse to a specific URL to expose the Flask config, including the SECRET_KEY variable.

Details

Any unauthenticated user can browse to a specific URL to expose the Flask config, including the SECRET_KEY variable.

PoC

Run pyload in the default configuration by running the following command

pyload

Now browse to http://localhost:8000/render/info.html. Notice how the Flask configuration gets displayed. PoC

I was quite amused by this finding. I think it's a very interesting coming together of things that is so unlikely to happen. Below I will detail my process a bit more.

I was looking through the code to see how the authorization mechanism is implemented when I spotted this route, which can be accessed by any unauthenticated actor

@bp.route("/render/<path:filename>", endpoint="render")
def render(filename):
    mimetype = mimetypes.guess_type(filename)[0] or "text/html"
    data = render_template(filename)
    return flask.Response(data, mimetype=mimetype)

This route allows me to load in any of the predefined templates. However, these templates will be lacking any form of context, and as such it doesn't seem too useful. That is until I loaded the info.html template and scrolled down, revealing the Flask config. This was purely accidental, and I did not understand why it happened, until I looked at the template

    <tr>
        <td>{{ _("Config folder:") }}</td>
        <td>{{ config }}</td>
    </tr>

In Flask, every template always gets the Flask config passed to it as the config variable. In the normal execution of this template, this value gets overwritten in the function below, but since we're calling it and bypassing this function altogether, it doesn't get overwritten. Would this variable not be named config and named configuration or Config instead, then this exploit wouldn't work. The likelihood of this occurring is so small, but it seems to have happened here.

    context = {
        "python": sys.version,
        "os": " ".join((os.name, sys.platform) + extra),
        "version": api.get_server_version(),
        "folder": PKGDIR,
        "config": api.get_userdir(),
        "download": conf["general"]["storage_folder"]["value"],
        "freespace": format.size(api.free_space()),
        "webif": conf["webui"]["port"]["value"],
        "language": conf["general"]["language"]["value"],
    }
    return render_template("info.html", **context)

Impact

Depending on the how the Flask config data is used, it could have detrimental consequences for the security. It's crucial to keep the SECRET_KEY secret and never expose it in your code or configuration files.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIpyload-ngall versions0.5.0b3.dev77
Exploits & PoCs
1

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pyload-ng. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update pyload-ng to 0.5.0b3.dev77 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mqpq-2p68-46fv is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-mqpq-2p68-46fv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-mqpq-2p68-46fv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary Any unauthenticated user can browse to a specific URL to expose the Flask config, including the `SECRET_KEY` variable. ### Details Any unauthenticated user can browse to a specific URL to expose the Flask config, including the `SECRET_KEY` variable. ### PoC Run `pyload` in the default configuration by running the following command ``` pyload ``` Now browse to `http://localhost:8000/render/info.html`. Notice how the Flask configuration gets displayed. ![PoC](https://user-images.githubusercontent.com/44903767/294522246-4cc19c49-b315-4926-8fd6-ec3c3fdb7c1f.png) I was quite amused
O3 Security · Impact-Aware SCA

Is GHSA-mqpq-2p68-46fv in your dependencies?

O3 detects GHSA-mqpq-2p68-46fv across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.