MB-R064 — Risky forks replacing originals

Why it Matters

Sometimes the original extension repository disappears or is abandoned, and a fork is published as a replacement. Not all forks are trustworthy — some may be maintained by unknown parties, lack security review, or even include malicious code. Installing risky forks in production exposes the store to supply-chain attacks.

Flagging extensions that depend on forks instead of original vendor repositories ensures administrators are aware of potential risks and validate the fork’s trustworthiness before adoption.

Verification Steps

# Inspect composer.json
cat composer.json | grep repositories -A3

# Check if source points to a fork (e.g., GitHub user repo instead of original org)

# API call to check if repo is a fork
curl https://api.github.com/repos/user/module | grep fork

# Expected: fork=false for originals; fork=true requires manual trust review

Remediation / Fix Guidance

1. Audit all extensions that rely on forks instead of vendor repos.
2. For each fork:
   • Check maintainer reputation, commit history, and community adoption.
   • Review diffs vs original code to ensure no backdoors or insecure changes were introduced.
   • Prefer forks managed by trusted organizations, not unknown individuals.
3. If risk is unacceptable, replace the forked extension with an official alternative.
4. Maintain an internal fork only if your team commits to patching and reviewing code securely.

Examples

# composer.json
"repositories": [
  { "type": "vcs", "url": "https://github.com/randomdev/module" }
]
# Random fork replaces original vendor repo, no reputation → FAIL

# composer.json
"repositories": [
  { "type": "vcs", "url": "https://github.com/magento-engcom/module" }
]
# Fork maintained by trusted org with transparent history → PASS

References

• OWASP Top 10 — A06: Vulnerable and Outdated Components
• OWASP — Software Supply Chain Security