← Back to Baseline

Why it Matters

Security fixes often exist, but your project cannot install them because of strict Composer constraints. Examples include exact version pins (e.g., ==2.4.3), narrow ranges, PHP platform locks (e.g., "platform": {"php": "7.4.33"}), or conflicts defined by other packages. When constraints block upgrades, known vulnerabilities remain in production.

Flagging these blocking rules makes the risk visible and actionable. Once identified, teams can widen constraints, bump the PHP platform, or resolve conflicting packages so that patched versions can be installed quickly and safely.

Verification Steps

Composer diagnostics

# 1) List outdated packages (direct deps only)
composer outdated --direct

# 2) See why a target fixed version cannot be installed
composer why-not vendor/extension 2.4.5

# 3) Inspect constraint details and conflicts
composer why vendor/extension
composer show vendor/extension -a

# 4) Check for platform locks that block upgrades
cat composer.json | jq .config.platform
# or
composer config --list | grep platform

# 5) Validate composer configuration for red flags
composer validate --no-check-all

Remediation / Fix Guidance

  1. Replace exact pins with caret ranges to allow security patches:
    # Bad (blocks patches)
    "vendor/extension": "2.4.3"
    
    # Good (allows >=2.4.5 within same major)
    "vendor/extension": "^2.4.5"
  2. Update PHP platform to meet the patched package requirements:
    # composer.json
    "config": {
      "platform": { "php": "8.2.999" }  # set to actual runtime or remove lock entirely
    }

    Ensure the server actually runs the specified PHP version.

  3. Resolve conflicts/replace rules:
    • Remove custom conflict/replace that block the target version unless strictly needed.
    • Eliminate legacy forks in repositories that pin old releases.
  4. Allow dependency graph to move with the fix:
    # Safely update a vulnerable package and its deps
    composer update vendor/extension --with-all-dependencies
  5. If the current vendor cannot fix quickly, evaluate a maintained alternative or temporary mitigation (see MB-R053).

Examples

Fail Example
# composer.json
"require": {
  "vendor/extension": "2.4.3"   # exact pin
},
"config": {
  "platform": { "php": "7.4.33" }  # old PHP lock
}

$ composer why-not vendor/extension 2.4.5
- Root composer.json requires vendor/extension (2.4.3) -> no matching package found (2.4.5 blocked)
# Result: cannot install patched 2.4.5 → FAIL
Pass Example
# composer.json (after fix)
"require": {
  "vendor/extension": "^2.4.5"
},
"config": {
  "platform": { "php": "8.2.999" }
}

$ composer update vendor/extension --with-all-dependencies
# Installs 2.4.5+ and resolves CVE → PASS

References