Adobe publishes a security advisory every time a vulnerability is patched in Magento Open Source or Adobe Commerce. In theory this is a useful signal. In practice, the feed is noisy enough that store operators either ignore it entirely or treat every bulletin as a five-alarm fire. Neither response serves you well.
This is how I read the feed, what I act on immediately, and what I file away for the next maintenance window.
Where the advisories live
Adobe publishes at helpx.adobe.com/security/products/magento.html. Each bulletin gets a permanent ID in the form APSB25-XXXX. That ID is what you want to track, not the title, because titles get reused in confusing ways across releases.
There is also an RSS feed at https://helpx.adobe.com/rss/security-updates.json (JSON, not XML) that includes all Adobe product bulletins. You will need to filter it down to Magento entries. More on that below.
If you prefer to watch GitHub, the Magento 2 security patch releases land on the magento/magento2 releases page with the advisory ID referenced in the release notes.
Decoding the severity rating
Adobe uses four levels: Critical, Important, Moderate, and Low. These map loosely to CVSS base score ranges, but Adobe rounds aggressively and applies product-specific context. A Critical in Magento is not always a 9.8 CVSS -- but it is always worth reading the detail.
What the levels mean in practice:
Critical -- unauthenticated remote code execution, unauthenticated SQLi, or authentication bypass that grants admin. These are the ones where the window between advisory and working exploit can be measured in hours. Patch the same day if you can. If you cannot patch same day, put a WAF rule in front of it and patch within 48 hours.
Important -- typically authenticated RCE, stored XSS that could lead to admin takeover, or significant data exposure. Patch within your next sprint. If the advisory mentions that exploitation requires only a customer-level account (not admin), treat it closer to Critical on a store with open registration.
Moderate -- CSRF, reflected XSS, limited information disclosure. Schedule it in the next planned maintenance window. Not something to wake up for.
Low -- defence-in-depth fixes, hardened defaults, minor information leakage. Bundle these into quarterly patch rounds.
The thing that overrides all of the above: a public proof-of-concept. More on that later.
Matching the advisory to your version
Every advisory lists the affected versions and the fixed versions in a table. This is where most operators go wrong, because the version numbering is not linear.
Adobe Commerce and Magento Open Source run on two separate tracks. An advisory might say "Fixed in 2.4.8, 2.4.7-p5, 2.4.6-p8". That means:
- If you are on the current release line (2.4.8), you need the full minor-version upgrade.
- If you are on an older supported line (2.4.7, 2.4.6), you only need the patch-level release for your line.
- If you are on an EOL line (2.4.5 and below as of early 2026), you are not listed because Adobe stopped backporting to those versions. You are exposed with no official patch.
The practical check: look up your version in composer.json or bin/magento --version, then find the -pN patch for your line in the advisory table. If your line is not in the table, check the Magento lifecycle policy to confirm whether it is still supported.
A Magento version being "recent" does not mean it is patched. I have seen stores running 2.4.7 that were exposed to a Critical because 2.4.7-p4 had been skipped. Check the exact patch number, not just the minor version.
Hotfix vs patch release: when each applies
Adobe sometimes releases an isolated hotfix -- a single Composer package that applies one fix without requiring the full patch upgrade. Hotfixes are rare but appear for the most severe CVEs when the coordinated disclosure timeline forces an out-of-band release.
You can recognise a hotfix advisory because the "Availability" section will say something like "Available as an isolated patch from Adobe Commerce Support". It will not appear on Packagist automatically; you apply it by downloading the patch file and using git apply or the Magento quality patches tool.
# Apply a hotfix using the Magento Quality Patches (MQP) tool
composer require magento/quality-patches
vendor/bin/magento-patches apply MDVA-XXXXXFor the vast majority of advisories, you want the regular Composer update:
composer require magento/magento2-base:2.4.7-p5 --no-update
composer update magento/magento2-base magento/framework --with-all-dependencies
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:cleanPinning the exact version in composer.json before running update prevents Composer from pulling in unrelated upgrades at the same time. Patch releases are supposed to be backwards-compatible, but mixing a security patch with a minor dependency bump complicates rollback if something breaks.
What to do when a patch lands mid-release
You are three weeks into a feature release. A Critical advisory drops. Do you halt the release?
Usually: deploy the security patch to production on its own, then rebase your feature branch onto the patched version. The patch release should not conflict with normal development work -- it touches the same files in lib/internal and vendor/magento that you typically do not modify directly.
The one exception is if your release includes changes to the security-relevant modules the patch touches. Check with git diff origin/main vendor/magento/module-security vendor/magento/module-customer before you rebase. If there are conflicts, resolve them before deploying the patch, not after.
The general principle: a Critical security fix ships ahead of every feature. An Important fix ships in the next maintenance window unless your feature release is going out within 72 hours anyway.
The public PoC reality
A public proof-of-concept changes everything. An advisory rated Important with an available PoC is more dangerous in practice than a Critical advisory with no public exploit code.
When a PoC drops:
- Automated scanners pick it up within hours. Your store will be probed before you have finished reading the advisory.
- The effective criticality moves to Maximum regardless of the official CVSS score.
- The patching window collapses. 48 hours becomes the outer limit; same-day is the goal.
Signs that a PoC exists: the advisory references a researcher disclosure, the CVE entry on cve.org links to a public report, or you see Magento-specific exploit traffic in your WAF logs.
What you can do if you cannot patch immediately:
- Enable two-factor authentication on all admin accounts if it is not already on.
- Tighten your WAF rules to block the request patterns described in the advisory.
- Restrict
/admin(or your custom admin path) to known IP ranges if your operations allow it. - Review recent admin logins and order activity for anomalies.
None of these are a substitute for patching. They buy time, not immunity.
Setting up a filtered feed
The Adobe JSON feed includes every product, which is a lot of noise if you only care about Magento. Here is a curl + jq one-liner that filters down to Magento/Commerce entries and prints the ID, date, and title:
curl -s "https://helpx.adobe.com/rss/security-updates.json" \
| jq '[
.items[]
| select(.title | test("Magento|Commerce"; "i"))
| { id: .id, date: .date_published, title: .title, url: .url }
]'If you want to run this as a daily check and only alert on new entries, pipe the IDs to a file and diff against the previous run:
#!/usr/bin/env bash
FEED_URL="https://helpx.adobe.com/rss/security-updates.json"
SEEN_FILE="$HOME/.magento-advisory-seen"
touch "$SEEN_FILE"
curl -s "$FEED_URL" \
| jq -r '[
.items[]
| select(.title | test("Magento|Commerce"; "i"))
| .id
][]' \
| while read -r id; do
if ! grep -qxF "$id" "$SEEN_FILE"; then
echo "NEW ADVISORY: $id"
echo "$id" >> "$SEEN_FILE"
fi
doneDrop this into a cron job and point the output at Slack, email, or wherever your team monitors alerts. You will get a notification for new bulletins without having to check the page manually.
What I actually look at in an advisory
When a new bulletin lands, I read it in this order:
- Affected versions -- am I on the list?
- Severity -- Critical or Important?
- Authentication required? -- unauthenticated vulns move to top priority immediately.
- Known exploitation? -- Adobe will say "Adobe is aware of limited attacks exploiting this vulnerability" if there is active exploitation. That sentence triggers same-day patching.
- CVE IDs -- I check each CVE on cve.org for published PoCs, researcher reports, and CVSS vector details.
The CVSS vector string is more useful than the score alone. AV:N/AC:L/PR:N/UI:N (network, low complexity, no privileges, no user interaction) is a worst-case attack profile regardless of the final score. If you see that vector on anything above Low severity, treat it as Critical.
Staying on a supported version
None of this matters if you are running an EOL version of Magento. Adobe stops backporting patches to unsupported release lines, which means Critical vulnerabilities will exist in your version with no official fix available. This is not a hypothetical risk -- I have triaged compromised stores where the attack vector was a known CVE that had been patched in the current release line for over a year.
If your store is on an EOL version, the security conversation starts there, not with any individual advisory. For more on the kind of work involved in getting a store current and hardened, see my security services or the Ice Headshop case study, which covers some of what sustained Magento maintenance looks like over multiple years.
A practical triage checklist
When a new advisory lands:
- [ ] Is my version in the affected range?
- [ ] What is the severity and the CVSS vector?
- [ ] Is authentication required to exploit it?
- [ ] Is there a public PoC or known active exploitation?
- [ ] Is there a patch for my release line, or do I need a hotfix?
- [ ] Does the patch conflict with any in-progress work?
- [ ] Schedule: same-day, next sprint, or next maintenance window?
Keeping a log of which advisories you have reviewed and what action you took takes about five minutes per bulletin. Over time it becomes useful evidence that the store is being actively maintained -- something clients and compliance reviewers occasionally want to see.