Some extensions rewrite core, and you should know which
Extensions change Magento behavior in different ways, and not all ways carry the same risk. The ones that replace core classes or stack around-plugins on core methods are the fragile end of the spectrum.
These techniques work, and they are sometimes the only option, but they couple the extension tightly to core internals. That coupling is what breaks on upgrades and creates hard-to-trace conflicts, so knowing which extensions do it is a real audit finding.
This article covers why class rewrites and around-plugins are risky, how to find them in installed extensions, and how to turn that into a risk inventory.
Why class rewrites are fragile
A class rewrite, done through a preference, replaces a core class entirely. The extension now owns every method in that class, including the ones it never meant to change.
When Magento updates that class in a release, the rewrite does not get the update. Behavior quietly diverges, and only one preference can win, so two extensions rewriting the same class conflict outright.
This makes rewrites both an upgrade risk and a conflict risk at once. They are the heaviest way to change behavior, and the one most likely to break when the platform moves.
Why around-plugins carry their own risk
An around-plugin wraps a method and controls whether the original runs. That control is powerful and easy to misuse.
Around-plugins also add overhead, since the method now runs through a wrapper on every call. Stacked several deep on a hot method, they turn a simple call into a chain of wrappers, and a mistake anywhere in that chain affects everything after it.
Finding class rewrites
Class rewrites are declared in di.xml as preferences, which makes them searchable. Grepping the extension configuration surfaces every one.
grep -rn "<preference" vendor/*/*/etc app/code/*/*/etcEach preference names the core class being replaced and the class replacing it. A preference on a core class, especially one in checkout, sales, or catalog, is a rewrite worth reviewing closely.
Finding around-plugins
Around-plugins are methods named with an around prefix in plugin classes. They can be found by searching the plugin code across extensions.
grep -rn "public function around" vendor/ app/code/Each hit is an around-plugin, and the method name after around tells you which core method it wraps. The ones to scrutinize are those on frequently-called methods and those that may not call the original consistently.
Reading what the rewrite actually changes
Finding a rewrite is the start, not the conclusion. The next question is what it changes and why, because some rewrites are reasonable and others are shortcuts that a plugin would have handled safely.
Read the replaced class or the around-plugin against the core it wraps. A rewrite that changes one small behavior, where a targeted plugin would have done, is carrying far more upgrade risk than the change requires.
This reading is what separates a justified rewrite from a fragile one. The technique is only as risky as what it is used for.
Building the risk inventory
The point of finding these is to rank them. A list of every preference and around-plugin across installed extensions is a map of where the code base is most coupled to core internals.
Rank them by blast radius and by how deeply they touch upgrade-sensitive areas. A rewrite of a checkout class from an abandoned vendor is a higher priority than an around-plugin on a rarely-used admin method.
This inventory feeds directly into upgrade planning. The rewrites and around-plugins on the list are the code most likely to need attention when the platform moves.
Not automatically wrong, always worth knowing
Class rewrites and around-plugins are not automatically defects. They are legitimate tools that happen to carry more risk than the alternatives, and sometimes they are the right choice.
What matters is knowing where they are. An extension that quietly rewrites a core class is a fact you want in hand before an upgrade, not a surprise you discover when the upgrade breaks.
The audit value is visibility. You cannot plan around coupling you have not found, and these techniques are exactly the coupling that makes upgrades unpredictable.
Know your coupling before you upgrade
The extensions that rewrite core and stack around-plugins are the ones most likely to break when Magento changes underneath them. Finding them is a search away, and ranking them turns a hidden risk into a planned one.
Knowing which of your extensions are tightly coupled to core internals is essential input for any upgrade or stability plan. Producing that inventory is a standard part of a module-risk review.