Bug bounty work taught me to build the full attack chain before arguing severity. An insecure registry line looks like a low-severity misconfiguration until you actually show what it lets an attacker do, so I built the chain rather than just reporting the setting.
What I built
Found an .npmrc in a public repository configured with registry=http://registry.npmjs.org/, which is unencrypted transport for package installs.
Stood up a mitmproxy man-in-the-middle proof of concept that intercepts the HTTP npm traffic and substitutes a package carrying a post-install script.
Demonstrated arbitrary code execution on install from that position, which is what turns "uses HTTP" into a real supply-chain risk to a developer machine or CI runner.
Reported it through Bugcrowd and made the severity case from the demonstrated RCE impact; it was raised from P4-Low to P2, and the repo moved to HTTPS after disclosure.
Backed the argument with a CVSS 3.1 score of 8.9 (High) using the vector AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H, so the reviewer had a defensible number, not just a narrative.
Screenshots
A walk through the build in screenshots. Click any to view it full size.
Fig 1The insecure HTTP .npmrc configuration
What I learned
Severity is an argument you make with a working chain, not a label you attach to a setting. The escalation happened because the PoC made the impact concrete.
The interesting security bug is often a boring config line whose consequences nobody walked all the way through.