A patch you applied may not be protecting you
Applying a security patch feels like closing a hole. Sometimes it is not, because a core override in a custom module or a hand-edited file means the patched code is not the code actually running.
The store reports the patch as applied, and the vulnerable behavior still executes through an override that Magento's fix never touched. This is one of the more dangerous gaps we find, because it hides behind a false sense of safety.
This article covers how core overrides block patches, the forms they take, how to detect them, and how to confirm a patch is really protecting the running code.
How an override neutralizes a patch
Security patches change core code. If a custom module has replaced that core class, or a plugin wraps the exact method being fixed, the patch changes code that no longer runs the way Magento assumes.
The patched file is still there, but the request flows through the override instead. The fix is present on disk and absent from the execution path, which is the worst of both worlds.
This is why "we applied the patch" is not the same as "we are protected." The two only match when nothing intercepts or replaces the code the patch corrected.
Preferences that replace the patched class
The clearest case is a preference. When a module declares a preference for a core class, that custom class runs everywhere in place of the original.
If the vulnerable logic lived in the replaced class, the override has to be updated to include the same fix. Otherwise the store carries the vulnerability inside its own custom code, invisibly.
Plugins around the patched method
Plugins are subtler. An around plugin that wraps the patched method can change its behavior, and depending on what it does, it may bypass or undermine the fix.
A before plugin that alters inputs, or an around plugin that conditionally skips the original, can each defeat a patch that assumed the method ran normally. The patch is applied, but a plugin changed the conditions it depends on.
This requires reading the plugins on any method a security patch touches. A plugin that looked harmless can become a security gap once the method it wraps is the one being fixed.
Hand-edited vendor files
The crudest case is a core file edited by hand. Security patches are often distributed as diffs, and a diff will not apply cleanly to a file that was already modified.
Either the patch fails to apply, leaving the vulnerability open, or it is force-applied and the hand edit is lost or mangled. Both outcomes are bad, and both come from a file that should never have been edited in place.
This is the same problem as core file integrity from another angle. A modified vendor file does not just risk being overwritten; it can block the very patch meant to secure it.
Detecting the overrides
These are findable before a patch, and should be checked as part of applying one. The overrides live in specific, searchable places.
List the preferences declared across custom modules and extensions, grep the di.xml files for classes the patch touches, and review the plugins on the patched methods. For hand edits, a diff of the vendor directory against a clean install of the same version reveals anything modified in place.
The security advisory tells you which classes and methods a patch affects. Cross-referencing those against your overrides shows exactly where a patch might be blocked.
Confirm the patch covers the running code
The final step is verification, not assumption. After applying a patch, confirm that the code path it fixes is the one the store actually executes.
Where a preference or plugin sits on patched code, trace what really runs for the affected request. The question to answer is whether the fixed logic is in the execution path or shadowed by an override.
This is the difference between a patch applied and a patch effective. Only the second one actually protects the store.
Overrides are a patching liability
Every core override is a place a future patch might not reach. The more a store replaces and wraps core code, the more its patching has to be verified rather than trusted.
This is another reason to prefer minimal, well-chosen customization over broad overrides. Code that leans on preferences and around plugins for core behavior makes every security patch a question mark until it is checked.
Reducing those overrides is a security investment, not just a maintenance one. It keeps the patch path clear so fixes land where they are meant to.
Verify, do not assume
A security patch is only as good as its reach into the running code. Overrides, plugins, and hand edits can each leave the vulnerability live while the patch reports as applied.
Knowing which of your overrides touch patched code, and confirming each patch actually protects the executing path, is what turns patching from a checkbox into real protection. That verification is a core part of any security review.