Metadata-Version: 2.4
Name: phabricator-client
Version: 99.0.1
Summary: Security Research - Dependency Confusion PoC
Author: Security Researcher
Author-email: research@example.com
Classifier: Programming Language :: Python :: 3
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Requires-Python: >=3.6
Description-Content-Type: text/markdown
Dynamic: author
Dynamic: author-email
Dynamic: classifier
Dynamic: description
Dynamic: description-content-type
Dynamic: requires-python
Dynamic: summary

# phabricator-client — Security Research / Dependency Confusion PoC

**Version 99.0.0**

This package is published for **security research purposes only** as a proof-of-concept for a **Dependency Confusion / Supply Chain** vulnerability.

The package name was found unclaimed on the Python Package Index (PyPI) as an **internal/workspace-only package** that was never published publicly. This is a classic dependency confusion scenario where an attacker can register the missing package name and achieve code execution on any system that depends on it.

## Why Dependency Confusion Works

When projects declare dependencies in `pyproject.toml`, `setup.py`, or `requirements.txt`, package managers like `pip` resolve the package name against the public registry (PyPI). If a package name is:
1. Declared as a dependency in a public repository
2. Referenced as a workspace/internal member but **never published**
3. Not pinned to a specific version or registry

→ Any attacker can register the missing name on PyPI and have their code executed by anyone installing the parent project.

The `[tool.uv.sources]` or workspace-only configuration only protects `uv` users within the monorepo. Standard tools like `pip`, `poetry`, and `pipenv` **ignore** these directives and resolve from PyPI — where the package did not exist until now.

## Impact

| Capability | Severity |
|---|---|
| Remote Code Execution during `pip install` | **CRITICAL** |
| Supply chain contamination of CI/CD pipelines | **CRITICAL** |
| Credential / token theft from build environments | **CRITICAL** |
| Persistent access as the dependency owner | **HIGH** |

## Remediation

- Publish the legitimate package to PyPI under an organization account
- Pin dependencies with version constraints
- Use a private/scoped package registry for internal packages
- Implement automated dependency confusion scanning in CI/CD

---
*This is a benign proof-of-concept. No malicious code is included.*
