chore: Fix on-headers vulnerability by overriding dependency

[oshikiri]

Summary

• add an npm override to force webpack-dev-server's compression dependency to use on-headers 1.1.0
• update the lockfile to resolve the override to the patched release

Testing

• npm ls on-headers

---

https://chatgpt.com/codex/tasks/task_e_6900cd7da550832badf2a5e7d52c64fa

Summary by CodeRabbit

• Chores
  • Improved dependency compatibility management for better stability.

[coderabbitai]

Walkthrough

A new "overrides" field is added to frontend/package.json to pin the transitive dependency "on-headers" to version ^1.1.0. This modifies dependency resolution behavior during package installation without affecting runtime code or existing direct dependencies.

Changes

Cohort / File(s)	Summary
Dependency override configuration frontend/package.json	Added top-level "overrides" field specifying "on-headers": "^1.1.0" to enforce a specific version of this transitive dependency during package resolution

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

🐰 A hop, a skip, a version pinned so tight,
On-headers now resolve just right!
Transitive paths once wild and free,
Now dance to harmony with me. 🌿

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The PR title "chore: Fix on-headers vulnerability by overriding dependency" accurately reflects the main change in the changeset. The pull request adds an npm override in frontend/package.json to force on-headers to version ^1.1.0 to address a vulnerability in a transitive dependency. The title is concise, specific, and uses clear language that conveys both the problem (on-headers vulnerability) and the solution method (dependency override), making it immediately understandable to anyone reviewing the git history. The "chore:" prefix appropriately categorizes this as a maintenance/configuration change rather than a feature or bug fix to production code.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch codex/fix-transitive-dependency-on-headers-vulnerability

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f78d62d and b908c8e.

⛔ Files ignored due to path filters (1)

• frontend/package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (1)

• frontend/package.json (1 hunks)

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

Verify the lockfile was updated and confirm the vulnerability is resolved.

The override syntax is correct and properly positioned. However, ensure:

1. The lockfile (package-lock.json) was updated to reflect the pinned version
2. Version ^1.1.0 is the correct fix for the on-headers vulnerability
3. No downstream compatibility issues arise from this constraint

Run the following to verify the resolution:

Additionally, could you confirm the specific vulnerability that version 1.1.0 addresses? Consider documenting the advisory ID or CVE in a comment for future reference.

---

🏁 Script executed:

#!/bin/bash
# Verify on-headers resolution matches the override
npm ls on-headers 2>/dev/null | head -10

# Check if lockfile exists and contains on-headers entries
if [ -f frontend/package-lock.json ]; then
  echo "--- Checking package-lock.json for on-headers entries ---"
  rg -n '"on-headers"' frontend/package-lock.json | head -5
fi

Length of output: 125

---

Let me also search for information about the on-headers vulnerability:

---

🏁 Script executed:

```shell
#!/bin/bash
# Check for all on-headers entries in lockfile to see version distribution
echo "=== All on-headers entries in package-lock.json ==="
rg -n '"on-headers"' frontend/package-lock.json

# Check if there are different versions pinned in the lockfile
echo -e "\n=== Checking for on-headers version pins in lockfile ==="
rg -n '"on-headers".*"' frontend/package-lock.json | grep -E '(~|\\^)' | head -20

Length of output: 181

---

🏁 Script executed:

#!/bin/bash
# Check all on-headers entries and their versions across the entire lockfile
echo "=== Complete on-headers entry lookup ==="
rg -B2 -A2 '"on-headers"' frontend/package-lock.json | head -40

Length of output: 190

---

🌐 Web query:

on-headers npm package vulnerability version 1.0.2 vs 1.1.0

💡 Result:

Summary — impact and difference

• on-headers@1.0.2 (and all versions <1.1.0) is vulnerable: passing an array to response.writeHead() can cause response headers to be inadvertently modified. This is tracked as CVE-2025-7339 (low severity). (security-tracker.debian.org)
• on-headers@1.1.0 contains the fix (commit c6e3849) and is the patched version; upgrade to ≥1.1.0 to remediate. (security-tracker.debian.org)

Workaround if you cannot upgrade immediately

• Pass an object (not an array) to response.writeHead(), e.g. response.writeHead(200, { 'Content-Type': 'text/plain' }). (vulert.com)

References

• Debian/security tracker (CVE details & fixed version). [1]. (security-tracker.debian.org)
• Snyk package advisory for on-headers (notes vulnerability and upgrade to 1.1.0). [2]. (security.snyk.io)
• GitLab / other advisories summarizing CVE-2025-7339 and the fix. [3]. (advisories.gitlab.com)

If you want, I can give the exact git/commit diff or a patch snippet showing the change.

Citations:

• 1: https://security-tracker.debian.org/tracker/CVE-2025-7339?utm_source=openai
• 2: https://security-tracker.debian.org/tracker/CVE-2025-7339?utm_source=openai
• 3: https://vulert.com/vuln-db/CVE-2025-7339?utm_source=openai
• 4: https://security-tracker.debian.org/tracker/CVE-2025-7339?utm_source=openai
• 5: https://security.snyk.io/package/npm/on-headers/1.0.2?utm_source=openai
• 6: https://advisories.gitlab.com/pkg/npm/on-headers/CVE-2025-7339/?utm_source=openai

---

Regenerate package-lock.json to apply the override—lockfile is currently stale.

The override syntax is correct and targets the proper fix for CVE-2025-7339 affecting on-headers < 1.1.0. However, package-lock.json still contains "on-headers": "~1.0.2" (line 965), meaning the override has not been applied. You must run npm install to regenerate the lockfile and ensure the vulnerability is actually patched before merging.

🤖 Prompt for AI Agents

In frontend/package.json around lines 37 to 39 the "overrides" entry for
"on-headers": "^1.1.0" is present but package-lock.json still pins "on-headers":
"~1.0.2", so the lockfile is stale; run npm install (or npm ci then npm install
if using CI constraints) in the frontend directory to regenerate
package-lock.json so the override is applied, verify package-lock.json now
references on-headers >=1.1.0 (or the patched version), run npm audit to confirm
the vulnerability is resolved, and commit the updated package-lock.json before
merging.