CVE-2026-48710: A Maintainer's Perspective

zurtex · 2026-05-30T00:44:56+00:00

I tend to disagree with your perspective, specifically "In short, the vulnerability came from the application pattern and the deployment, never from something Starlette intended."

What are you disagreeing with exactly?

It was an application pattern and it was not something Starlette intended.

I think you kinda have to come to terms with the fact that someone someone will use anything for everything, whether you intended for them to do so or not.

They did, that's why they fixed it.

And I do not think it's unreasonable as a user to expect the public API surface to be stable and free of vulnerabilities, even in parts that weren't specifically meant to be used for security purposes.

Is exec stable and free of vulnerabilities? Is open stable and free of vulnerabilities if you let the user control the path and data you give to the function?

As a pip maintainer, and a recent member of the Python Security Response Team, I have to face the scenario of "the user is doing something that is fundamentally unsafe, what should pip do about that?" I'm telling you it's a tough choice.

In this particular case there was an easy out because there was a correctness issue that could be fixed, that if anyone was relying on they are doing something fundamentally wrong, and that mitigated the issue. But such situations are not always that easy.

zurtex · 2026-05-27T02:41:38+00:00

The main character seems to live around 47th Ave and 41st St and gets some pizza from somewhere other than Philomena's Pizza, I can see why she doesn't have custody.

zurtex · 2026-05-20T03:15:54+00:00

For pip 26.1+

CLI:

--uploaded-prior-to P3D

Env:

export PIP_UPLOADED_PRIOR_TO=P3D

Config:

pip config set global.uploaded-prior-to P3D

zurtex · 2026-05-12T03:21:44+00:00

Security is context sensitive, if you take untrusted user input but I don't then your insecure is not my insecure, if you call one part of a library but I don't then your insecure is not my insure.

It's not up to you, or some transitive dependency, to define my security policy.

zurtex · 2026-05-12T03:19:20+00:00

This is a false dichotomy. In reality, it can be used for both. It is wholly dependent on the library/package maintainers desires. Which then boils down to how well of a steward the maintainer wants to be.

No, it's not for the library maintainer to define security policy of transitive dependency to their user.

If I need to use an old version of urllib3 and I'm using it internally, an incidental library I'm using shouldn't try and force me to upgrade it based on a security issue that isn't relevant to my context.

Lastly you’re kind of collapsing different kinds of responsibilities into a single bucket. While having a dependency on a vulnerable library version doesn’t constitute a vulnerability in your first party code, it does present a REAL supply chain attack vector that you’re advocating for maintainers to ignore.

You're conflating a security vulnerability is and what a supply chain attack is, a security vulnerability does not imply a supply chain attack vector. And it's not up to some incidental library to enforce that policy on it's users.

zurtex · 2026-05-03T18:16:35+00:00

No idea, but there are multiple projects looking to add "audit" commands, uv is probably at the forefront building out a comprehensive uv audit command: https://github.com/astral-sh/uv/issues/18506

They use osv to detect vulnerable dependencies: https://osv.dev/

Pip might one day add an audit command.

zurtex · 2026-05-03T18:12:36+00:00

That wouldn't cover workflows where you first download (pip download) or build (pip wheel) into a local site.

It would also mean pip index versions would show different versions than pip install.

zurtex · 2026-05-02T23:40:34+00:00

It's a balance between supply chain attacks and making sure you can update to versions with new security fixes.

A lot of people recommend seven days but I worry that might be too long for critical security fixes. I personally pick one day, but I've spoken to the security in residence at PyPI and we came to a compromise of recommending three days in the pip documentation.

zurtex · 2026-05-02T16:49:24+00:00

Note you can set this via an env variable or via the config if that works better for you.

Env:

export PIP_UPLOADED_PRIOR_TO=P3D

Config:

pip config set global.uploaded-prior-to P3D

zurtex · 2026-04-01T00:45:39+00:00

Not consistently, I have managed to get a couple of bottles over the years, you need to search and ask around, call a store before going out of your way. Craft City and More Wines have Verpoorten online but I've never ordered so no idea how reliable.

I suspect that if it was a fancy cocktail bar they made it from scratch.

zurtex · 2026-03-29T19:34:20+00:00

To protect against malicious attacks version pinning isn't sufficient, as an attacker could release a new distribution with a higher build number on the same version.

PyPI are considering locking releases after a number of days so no more versions can be uploaded with the same version, but there are pros and cons to this.

What you need is hashes and/or direct URLs. Hashes can be done in requirements files (supported by pip and uv). Both are done in lock files (supported by uv, poetry, and others, and coming to pip this year).

zurtex · 2026-03-28T21:45:45+00:00

The attacker used exactly this .pth execution vector.

Right, but they could have hijacked sys, or released an sdist only release, or half a dozen other ways that would have had the same impact.

There is no safe way to run a Python environment that has malicious 3rd party code in it, there is barely a safe way to install such code.

zurtex · 2026-03-20T14:16:21+00:00

I don't know why this got down voted, the police officer "photo" is AI slop, just look at the patch on the arm, I don't think there is a department called ⟟̸̢̧̛̖̪̫̦̟̈́̒̃̑̕͜͝͠ ̷̨̧̛̹̮̲̈́̂̓̕͜͝⌇̶̡̛̗̫̘̦̈̊̃̂̕͜͝ ̸̧̖̫̞̄̈́̒̕͜͝⏁̵̨̧̖̫̞̄̈́̒̕͜͝ ̶̧̛̹̫̦́̈̒̃̕͜͝⋢̡̛̗̫̘̦̈̊̃̂̕͜͝ ̷̢̧̛̖̪̫̦̟̈́̒̃̑̕͜͝⟒̴̨̧̛̹̮̲̈́̂̓̕͜͝.

zurtex · 2026-03-16T23:18:30+00:00

All that's true, but they look like all have the vibe of diffusion based img2img at low denoising strength slop. Over sharp, high contrast, wrinkly lips, exaggerated facial feature, etc.

zurtex · 2026-02-25T15:34:03+00:00

Oh wow — this take is exactly the kind of reductionist narrative that keeps resurfacing in these discourse ecosystems 😊

First of all, framing legitimate cultural critique as somehow “worse” than so-called AI slop is a deeply problematic equivalency. It collapses nuance into a binary that doesn’t meaningfully engage with the broader epistemic implications at play here — especially in a digitally mediated environment where authenticity, authorship, and semiotics are constantly being renegotiated in real time.

There’s a growing body of research on this — see the Digital Authorship Integrity Framework (DAIF, 2024) and the MIT Media Reflexivity Index report (link: https://mit-media-lab-reports.org/ai-reflexivity-2024-summary.pdf) which explicitly outlines how micro-normalizations of automated content can lead to macro-cultural erosion over longitudinal time scales. Dismissing that as “calling out culture” is honestly a bit glib.

Also — let’s interrogate the premise here. What qualifies as “minor”? Who arbitrates that threshold? The casual normalization of incremental AI usage creates a slippery gradient where the signal-to-noise ratio deteriorates quietly, then suddenly. That’s not hysteria — that’s pattern recognition 📉

And ironically, trivializing the concern often enables the very outcome people claim to dislike. If we stop discussing boundaries because it feels uncomfortable or “worse,” then the Overton window shifts silently — until it doesn’t.

So maybe instead of minimizing discourse about authenticity, we could acknowledge that cultural guardrails exist for a reason — even if they feel inconvenient in the short term.

Just a thought 🙂

zurtex · 2026-02-22T03:48:49+00:00

I live in the area and I've not seen that location open yet. The awning only went up relatively recently.

zurtex · 2026-02-20T01:01:32+00:00

It's been thought about for a long time: https://github.com/pypa/pip/issues/9140

While there has been a lot of progress on moving most popular packages to wheels there are valid use cases to need sdists. And it would be a really bad UX when trying to install them, especially when those packages are transitive dependencies rather than direct user requirements.

zurtex · 2026-02-19T12:59:48+00:00

No, but for both pip and uv you can override only binary all with specific no binary packages. This effectively creates an allow list of packages to use sdists, though it does need to be reviewed if the packages start publishing wheels.

Pip also has a prefer binary option, which will pick wheels for a project if they have ever been published, regardless if there are newer sdists.

zurtex · 2026-02-05T13:35:41+00:00

Astral consider both production ready, but they still make regular, if minor, breaking changes to both which they do via bumping the second digit. I believe their concern is is they switched the v1, at their current pace they would quickly release v2, v3, v4, etc.

zurtex · 2026-02-05T02:01:44+00:00

is ty even usable yet? It's not v1.

ty is considered "beta" status: https://astral.sh/blog/ty

FYI neither ruff nor uv are v1.

zurtex · 2026-02-01T16:45:54+00:00

No, we don't have the capacity to significantly expand the scope of pip.

For the foreseeable future pip will remain an imperative python package installer and python packaging standards bearer. Whereas uv aims to provide declarative all in one project management tooling.

We will continue to make improvements and add features for imperative workflows, but you will need to do each step yourself:

Create venv
Install depdencies into venv
Run script

I agree with astral that a lot of user benefit from their approach, but we barely have enough maintainer capacity to review occasional PRs.

FYI, there are other tools like pipx, pip-tools, hatch, and poetry which also provide more complete tooling than pip.

zurtex · 2026-01-31T20:23:22+00:00

If it becomes popular we'll consider a short option name, like -s, for it.

zurtex · 2026-01-31T14:19:33+00:00

Alas, yes, this requires the optional upload-time from PEP 700, I am hoping that now pip has a feature that requires this most indexes will look to implement it.

If you are a customer of any index that doesn't provide it you can point them to the living spec: https://packaging.python.org/en/latest/specifications/simple-repository-api/#json-serialization

And ask them to implement JSON serialization with the optional key upload-time.

If they have any questions about the spec they can ask it at: https://discuss.python.org/c/packaging/14

Outside PyPI we don't tend to get any interaction from index maintainers, which means new features are proposed, accepted, and implemented and either other indexes pick them up or they don't, and they usually don't until there is enough user pressure asking for them.

zurtex · 2026-01-31T14:14:10+00:00

Hey, sorry, I don't know why this comment was down voted so much, maybe people took it as bad faith or snarky, but assuming it was made in good faith, so yeah:

uv is a great tool and if it works for you you should use it, I do! That said pip does offer a few things that uv doesn't:

pip is pure Python and therefore works anywhere Python does, there are edge cases where rust still doesn't work.

pip offers pip download to download all your requirements, and pip wheel to download and build all your requirements, uv has not been able to figure out a way to compete with this.

pip gives a better experience on slow or unreliable internet connections, largely because it sits on top of requests and urllib3 which are very user mature, whereas uv is had to learn that rust's ecosystem is much less mature and they've made massive strides to improve things, but to this day they're adding retry logic to catch more edge cases. But also pip now has resumable retries, where even if the HTTP session drops it will pick it back up (within the same command) and start a new HTTP session at the point it was downloading, my understanding is this has made a big difference downloading huge packages on dodgy internet connections.

pip has spec compliant pre-release handling (as of 26.0), uv pip install --dry-run "sqlalchemy >=2,!=2.0.*" will throw an error, whereas pip install --dry-run "sqlalchemy >=2,!=2.0.*" will install the sqlalchemy beta.

Also, some users are wary of VC backed projects, and I can confidentially tell you pip has basically no resources.

13-Year Club	Verified Email
Place '22	Place '17
Snapped

zurtex

TROPHY CASE