How do you list a CVE fix on your resume?

Why does the PHP emergency patch belong on your CV?

Because emergency patching is the most visible engineering work people routinely leave off the page. On 21 October 2026, the PHP project shipped out-of-band releases — 8.5.12, 8.4.27, 8.3.36 and 8.2.35 — to fix two bugs nicknamed PHP2Shell, tracked as CVE-2026-109618 and CVE-2026-109619. Both scored 9.2 and both allowed unauthenticated remote code execution against any server handling PHP web requests. Government sites in Finland, the Netherlands and France went dark while teams patched, and national cyber agencies told everyone to update immediately. A follow-up advisory, CVE-2026-115560, landed two days later as a lower-risk informational note. Thousands of engineers cancelled their week and spent that Wednesday night rolling upgrades through production.

The scope is what made it ugly. The flaws touched essentially every way PHP serves a request — Apache with mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed — and application-level authentication offered no protection, because PHP processes the malicious request before your code ever runs. No official fix landed for PHP 8.1 and older, so teams sitting on end-of-life versions had to jump a whole minor version against a deadline. That meant inventorying every PHP workload, checking extension compatibility, staging canaries, writing a rollback plan and babysitting deploys. Exploitation attempts turned up in honeypot traffic days before public disclosure, which killed any argument for waiting until Monday.

Here's the part that costs people money. Six months from now, that night becomes a CV line reading "responsible for security patching and incident response" — and it dies on contact with a recruiter. You ran triage across a live fleet under adversary pressure and shipped the fix before anyone got in; the CV says you were responsible for a verb. Hiring managers for backend, DevOps, SRE and security roles are hunting for exactly that evidence, because operating calmly under a nine-point-something CVSS is the hardest thing to fake in an interview. Written properly, one emergency-patch bullet carries more weight than three lines listing your tech stack, and it gives the interviewer somewhere obvious to dig.

What's the exact bullet formula for a CVE on a resume?

Use five components in a single sentence: the CVE ID and its severity, the scope you covered, the time it took, the outcome you avoided, and the role you personally played. The template is [action verb] [CVE-ID] ([CVSS score]) across [scope] in [time], [impact avoided], [your role]. Written out for security: "Led remediation of CVE-2026-109618 (CVSS 9.2) across 240 PHP-FPM services and 1,400 containers in 11 hours, closing an unauthenticated RCE path with zero customer-facing downtime; owned the canary sequence and rollback plan." For DevOps: "Shipped a fleet-wide PHP 8.2.35 upgrade to 86 production hosts via Ansible in under 24 hours, no rollbacks, no SLO breach." Every clause carries a number or a concrete noun.

Scope is whatever you can count honestly: services, hosts, repositories, endpoints, a version range, or the number of teams you coordinated. Use the unit the job ad uses. Time-to-patch is the strongest number you personally own, so give it as a duration or a before-and-after — "11 hours from advisory to full fleet", or "cut critical-CVE remediation from 21 days to 4". Blast radius is the clause a non-engineer understands: unauthenticated RCE closed, credential and token exposure prevented, audit scope kept clean, no customer downtime. Then name your lane — incident commander, remediation owner, author of the playbook, the person who wrote the detection rule — because "we" bullets read as borrowed credit and interviewers probe them first.

Three mistakes sink these bullets. The first is the trivia line: a bare list of CVE IDs with no scope or outcome, which only proves you can read an advisory. The second is claiming the team's result as your own — if you were one of nine engineers on the incident bridge, write what you ran, not what the company achieved. The third is stacking: six CVE IDs crammed into one bullet reads like padding, so lead with the highest severity and widest scope and let a skills line cover the rest. And give every number a paper trail. If you can't say where "11 hours" came from, change it to something you can defend when a staff engineer asks.

Where does emergency patching belong on a backend, DevOps or security CV?

Inside the experience bullets for the job where you did the work — not in a standalone "CVEs" section, unless you're credited as the person who discovered and reported the vulnerability. For security engineers, patch and incident bullets belong first or second under your current role, above tooling and process work. For DevOps and SRE, put it beside your reliability and deployment-pipeline bullets, where it reinforces the same story about shipping safely at speed. For backend developers, third or fourth is right: your top bullets should still be about what you designed and shipped, with the emergency work as proof you can be trusted near production. Dated work helps too — a late-2026 bullet signals current, hands-on exposure.

The exception is genuine CVE credit. If your name appears in an advisory as the reporter, or you hold an ID from your own research, that earns its own short section — call it "Security research and disclosures" — listing the ID, the affected product and the year, and nothing more. Keep the distinction crisp, because recruiters conflate the two and senior interviewers never do. Discovering a vulnerability is research; remediating one is operations. Both are valuable and both get hired, but a CV that implies the first while delivering the second gets caught in the opening technical screen, and there's no recovering from that in the same conversation.

Match placement to the posting. A vulnerability management ad wants remediation SLAs, scanner coverage and severity triage in your top three bullets. A platform engineering ad wants the deploy mechanics: how you pushed a fleet-wide runtime upgrade without downtime, what you automated, how you verified. A product-backend ad wants one tight line, not three. If you're aiming at security roles specifically, order matters as much as wording — certifications near the top, your actual SIEM and EDR stack named, incident work written so it survives a reference check. A CV built around that structure stops you burying the bullet that would have won the interview.

Which keywords does an ATS scan for in vulnerability work?

Applicant tracking systems match the literal words in the job ad, so mirror its vocabulary exactly: CVE, CVSS, vulnerability management, patch management, remediation, mean time to remediate, incident response, on-call, severity triage, zero-day, CI/CD. Most parsers won't expand acronyms or guess synonyms on your behalf, so write "remote code execution (RCE)" once and "software composition analysis (SCA)" once, putting both forms on the page. If the ad says "patch compliance" and your CV says "update hygiene", you score nothing on that term no matter how good the underlying work was. Workday- and Greenhouse-style pipelines then rank what they extracted, which is why phrasing beats eloquence at this stage.

Name your tools, because tool names are the easiest keywords to match and the hardest to bluff. Scanners and dependency tooling: Tenable, Qualys, Rapid7, Snyk, Dependabot, Trivy, Grype, Semgrep. Orchestration you actually used to ship the fix: Ansible, Terraform, Kubernetes, Argo CD, Helm. Paging and coordination: PagerDuty, Opsgenie, Jira, Slack incident channels, a public status page. For a PHP story, name the runtime layer as well — PHP-FPM, mod_php, LiteSpeed, FrankenPHP, Composer — because those are precisely the words a hiring manager types when they need someone who has already survived the upgrade they're dreading. Specificity here doubles as proof of experience.

Put the keywords in the bullets, not in a keyword block at the bottom. A skills list proves vocabulary; a bullet proves use, and any experienced reader spots the difference in seconds. Keep one compact skills section that mirrors the ad's phrasing, then make sure every term that matters also appears in context above it. Version numbers are worth including sparingly — "migrated PHP 8.1 workloads to 8.3 across 60 repositories" is specific, verifiable and instantly credible. If you're rebuilding the document rather than patching it, an AI CV builder keeps the layout parseable in a single column while you spend your attention on the wording.

How do you write up a CVE fix without breaching an NDA?

Stick to public facts and your own actions. CVE IDs, CVSS scores and patched version numbers are published information, so you can name them freely. What's confidential is your employer's exposure: which versions they were running, how long they stayed unpatched, what an attacker reached, customer names, internal service names, and anything lifted from a post-incident review. The test is simple — would this sentence help someone attack your former employer, or embarrass them in public? If yes, abstract it. "Remediated a critical unauthenticated RCE across a 240-service PHP estate" tells a hiring manager everything useful and hands an attacker nothing at all.

Abstraction doesn't weaken the bullet, it just moves the detail. Swap client names for a category: "a top-five UK insurer", "a 40-million-user marketplace". Swap internal system names for function: "the payments authorisation service", not its codename. Round infrastructure counts instead of publishing an inventory, and never state the window during which you were exposed. Then resist overclaiming in the other direction. If the fix was a version bump owned by your platform team and your part was regression-testing thirty services, say that — "validated 30 services against PHP 8.3.36 in six hours, clearing the upgrade for production" is a genuinely strong bullet, and it holds up under any amount of questioning.

Then check the document rather than trusting your feeling about it. Run it through a free CV analysis and watch two scores in particular: impact and ownership, which tells you whether your bullets read as results or as duties, and ATS compatibility, which tells you whether a parser can read them at all. Paste the job description in as well and you'll see which of its skills your CV never mentions — usually the exact remediation vocabulary sitting in the ad. The whole value of that long night of patching is that it's provable work, done under real pressure. Write it so the proof survives the first automated screen.

Frequently asked questions