PyPI Explores Prefix Reservation for Organizations Under PEP 752 to Prevent Name Squatting
PyPI is considering a mechanism to reserve package name prefixes for organizations following the adoption of PEP 752 in June 2026. The proposal aims to link recognizable prefixes such as google-cloud-, opentelemetry-, and apache-airflow-providers- to verified owners, reducing the risk of name squatting and dependency confusion attacks.
Currently, PyPI treats all package names as independent entries in a flat namespace. Organizations like yandex-bot and seznam-bot have published hundreds of placeholder packages to protect prefixes, yet any user can still register new names that begin with familiar strings. PEP 752 introduces implicit namespaces so that control over a prefix automatically covers future packages matching the normalized name pattern.
Normalization rules mean that google.cloud.storage would fall under a reserved google-cloud- prefix, while google-cloudstorage would not. Projects matching an existing prefix but published by unauthorized accounts would receive a 409 Conflict error on upload. Existing packages retain the ability to publish new versions under grandfathering rules.
Data from CodeScoring covering more than 800,000 active projects reveals that no examined prefix belongs to a single owner. The aws- prefix is controlled by 743 accounts, google- by 484, and types- by 68. Even within narrower prefixes such as datasette-, multiple independent maintainers publish plugins.
The upcoming PEP 755 will define the application process. Only organization accounts may apply, prefixes must exceed three characters and already be in use by the applicant, and overly generic terms will be rejected. Large open-source projects, universities, and government entities may receive fee waivers, while paid organizations could receive faster review.
Unlike npm scoped packages, the Python approach keeps the flat namespace intact to avoid breaking existing tooling and dependency files. New metadata will allow clients and corporate proxies to enforce prefix ownership policies once support is added.
Related articles
Suspicious Certificate Issuer Detected in MAX Messenger Windows Update Package
A detailed observation from a security researcher highlights an unexpected change in the code signing certificate for the MAX messenger desktop client on Windows. The August update package was signed by an individual named Konstantin Syomochkin instead of the usual Communication Platform LLC. This discrepancy raised concerns about potential supply chain interference linked to recent EU sanctions against the developer. The certificate was issued shortly after sanctions and belongs to a person based in Astana, Kazakhstan, with limited public ties to the VK team. Official MSI installers downloaded directly from the MAX website remain signed by the company, while the client-triggered update differs in both version and signer. The researcher recommends that VK verify the download chain through Mail.ru trackers to rule out tampering. Installation of the update was declined pending further clarification.
LiteLLM Supply Chain Poisoning Exposes 195TB of Credentials Across 2500 Organizations
A detailed forensic report from CloudSEK and Hudson Rock reveals that attackers compromised the LiteLLM CI/CD pipeline by poisoning the Trivy security scanner dependency. The malicious Trivy tag allowed theft of PyPI publishing tokens, leading to the upload of tainted LiteLLM versions 1.82.7 and 1.82.8. Within a 40-minute attack window these packages were downloaded over 119,000 times, exfiltrating 195TB of credentials including AWS, Azure, GCP keys, GitHub tokens, SSH keys, Kubernetes configs, and AI provider API keys. NVIDIA and multiple other major technology firms were confirmed among the victims. The incident highlights critical weaknesses in dependency pinning practices and the absence of automated detection for malicious package behavior on PyPI. Experts warn that AI infrastructure components are becoming high-value targets for future supply-chain campaigns.
Linux Foundation Report Reveals Why Companies Fork Open Source Projects and Maintain Internal Patches
A new Linux Foundation Research study of 567 IT professionals shows that organizations actively modify open source components rather than using them unchanged. While 72% contribute back to projects in some form, many maintain internal forks due to missing features, integration needs, security timelines, and regulatory requirements. The average organization supports 86 internal forks, consuming over 5,000 hours per release cycle. The largest gaps between business-critical technologies and actual contributions appear in programming languages and databases. The findings highlight growing supply-chain risks when internal branches diverge from upstream projects without proper tracking of patches and commits.
Where Secrets Really End Up in Docker Images: Testing 8 Common Methods
A detailed analysis of eight different approaches for handling secrets during Docker image builds reveals that most methods leave sensitive data exposed in layers, configuration files, or build history. Experiments conducted on Ubuntu 24.04.1 LTS with Docker Engine 29.1.3 and BuildKit v0.26.2 showed that simply using RUN rm after COPY or overwriting files fails to remove secrets from immutable layers. Environment variables via ENV and build arguments via ARG both persist in image metadata and history. Only BuildKit Secrets with --mount=type=secret and multi-stage builds that avoid copying secrets into the final stage successfully prevent leakage. The study demonstrates that secrets can be extracted from saved images without running any containers. Developers are advised to adopt these two secure patterns to protect credentials in container supply chains.