1. Introduction
Composer Repository Credentials Disclosure is a vulnerability affecting systems using the Composer dependency manager for PHP. It occurs when credentials used to access private Composer repositories are exposed, allowing attackers read and write access. This impacts confidentiality (source code theft), integrity (malicious package injection) and availability (supply chain disruption).
2. Technical Explanation
Composer allows developers to manage PHP libraries from public or private repositories. Private repositories require authentication. If the credentials for these repositories are inadvertently committed to a source code repository, an attacker gaining access to that repository can use them to compromise the Composer packages and potentially inject malicious code into applications using those packages. The vulnerability is identified as CWE-200 (Information Disclosure). An example exploit involves cloning the compromised source code repository, extracting the credentials file, and then using these credentials to push a malicious package update to the private repository.
- Root cause: Composer repository credentials stored in plain text within files tracked by Source Code Management tools.
- Exploit mechanism: An attacker clones the source code repository containing the credentials, uses them to access and modify packages in the private composer repository.
- Scope: PHP applications using Composer with a private repository are affected.
3. Detection and Assessment
Confirming exposure requires checking for credential files within your source code repositories. Thorough assessment involves scanning all repositories for sensitive data.
- Quick checks: Use
git grep -n "composer auth" .in the root directory of your Composer projects to search for potential credentials files. - Scanning: Consider using a secrets scanner (e.g., git-secrets, truffleHog) to identify exposed credentials within repositories. These are examples only and may require configuration.
- Logs and evidence: Review commit history in source code management systems for any commits adding or modifying files containing “composer auth” strings.
git grep -n "composer auth" .4. Solution / Remediation Steps
The primary solution is to prevent Composer repository credentials from being tracked in source code management tools. If the file is required, enforce proper permissions. Exposed credentials should be rotated immediately.
4.1 Preparation
- Ensure you have access to rotate Composer repository credentials. A roll back plan involves restoring from backup.
- Change windows may be needed for larger projects, and approval from security or IT operations is recommended.
4.2 Implementation
- Step 1: Remove the file containing Composer repository credentials from source code management tracking using
git rm. - Step 2: Commit the change with
git commit -m "Remove composer auth file". - Step 3: Push the changes to your remote repository with
git push origin. - Step 4: Rotate any exposed credentials immediately by generating new authentication tokens within the Composer repository settings.
4.3 Config or Code Example
Before
# auth.json (example - do NOT commit this file!)
{
"github-oauth": {
"token": "YOUR_GITHUB_TOKEN"
}
}After
# Remove the auth.json file from your repository entirely. Use environment variables or other secure storage for credentials instead.4.4 Security Practices Relevant to This Vulnerability
- Least privilege: Limit access to Composer repositories and credentials to only those who need it.
- Secure defaults: Avoid storing sensitive information in plain text files within source code repositories.
- Input validation: While not directly applicable here, ensure any input used to generate or manage credentials is properly validated.
4.5 Automation (Optional)
# Example Bash script to scan repositories for composer auth files:
#!/bin/bash
for repo in $(git remote -v | awk '{print $1}'); do
echo "Scanning repository: $repo"
cd "$repo" || continue
if git grep -q "composer auth"; then
echo "WARNING: Found 'composer auth' string in $repo. Investigate!"
fi
done5. Verification / Validation
Verify the fix by confirming that the credentials file is no longer present in the source code repository and that new credentials have been rotated. Perform a smoke test to ensure Composer functionality remains intact.
- Post-fix check: Run
git grep -n "composer auth" .in the root directory of your Composer projects. The output should be empty. - Re-test: Repeat the scanning steps from Section 3 to confirm that no exposed credentials remain.
- Smoke test: Run
composer installin a sample project using the updated credentials to verify dependency installation works as expected. - Monitoring: Monitor source code commit logs for any accidental reintroduction of credential files containing “composer auth”.
git grep -n "composer auth" .6. Preventive Measures and Monitoring
Preventative measures include updating security baselines, adding checks to CI/CD pipelines, and establishing a regular patch review cycle. For example: use pre-commit hooks to prevent credential files from being committed.
- Baselines: Update your organization’s source code management baseline to explicitly prohibit the storage of credentials in repositories.
- Pipelines: Integrate secrets scanning tools into your CI/CD pipeline to automatically detect and block commits containing exposed credentials.
- Asset and patch process: Implement a regular review cycle for configuration files and scripts to identify potential security vulnerabilities, including accidental credential exposure.
7. Risks, Side Effects, and Roll Back
Removing the credentials file will break Composer functionality until new credentials are provided. Rolling back involves restoring the original repository state from backup.
- Risk or side effect 1: Removing the credentials file without providing replacements will cause Composer dependency installation to fail.
- Risk or side effect 2: Incorrectly configured permissions on the credentials file could lead to unauthorized access.
8. References and Resources
- Vendor advisory or bulletin: https://getcomposer.org/doc/articles/authentication-for-private-packages.md
- NVD or CVE entry: Not applicable – this is a general configuration issue, not a specific CVE.
- Product or platform documentation relevant to the fix: https://getcomposer.org/doc/articles/authentication-for-private-packages.md