Whether or not they are behind the affiliate link or there’s some kind of MIM/malware or similar attack remains to be seen. Unfortunately we live in a time where app repos are being compromised left and right so with the limited information in the article this was my view of the situation.
I understand what you’re saying, I’m saying the information we have doesn’t fit the behavior you’re equating this to.
Given they only had the issue when accessing it via the moto app drawer app on a limited number of phones and didn’t see it when side loading or loading the app from another store, that is evidence against an app compromise and is closer to the behavior seen in local compromises. Were this an app level compromise as you’re suggesting, the behavior wouldn’t disappear on different devices or when side loaded.
I could easily be wrong, I just don’t see the behavior I’d expect to see for a wide ranging own like a repo takeover.
I could potentially see this happing if it’s an app that this app talks to that’s compromised or perhaps if they have a second app installed that this app interfaces to/that is talking to this app to prompt this behavior.
It wasn’t clear to me if they attempted to duplicate this on the same hardware by wiping the device and then side loading the app/installing it from a different app store.
But I think that’s because this app is a stock app that can’t generally be deleted (only rolled back to a previous version) from my understanding. But I may be wrong about that. This definitely makes it sound like it was the most recent update that caused this behavior.
An app update on Motorola phones has started hijacking the Amazon app for the sake of injecting an affiliate code. To do that, tapping the app icon opens the user’s browser and immediately redirects to the Amazon app. It’s a “blink and you missed it” moment. This only happens when the user opens the Amazon app from the app drawer – not the homescreen pages.
Yeah, it’s a bit confusingly worded. A couple paragraphs down it starts to show how the behavior isn’t consistent
We verified on a Razr (2026) running an older Smart Feed v2.03.0056 that this does not happen. Our Razr Fold, with app version 2.03.0070, has started showing this behavior, so it’s the latest update that’s to blame for hijacking the user’s intent. We couldn’t replicate this on a Moto G Stylus (2026) running the same app version, though. Sideloading the app, for reasons unclear, doesn’t seem to trigger this behavior, as manually installing the updated version on the aforementioned Razr (2026) didn’t show the same behavior.
Just the fact that the same version installed other ways didn’t have the same behavior makes an app compromise conclusion hard to support. But you’re entirely right that this could be secondary app caused, potentially the update mechanism on the phone was compromised, which might explain why side loading didn’t have the same behavior.
I understand what you’re saying, I’m saying the information we have doesn’t fit the behavior you’re equating this to.
Given they only had the issue when accessing it via the moto app drawer app on a limited number of phones and didn’t see it when side loading or loading the app from another store, that is evidence against an app compromise and is closer to the behavior seen in local compromises. Were this an app level compromise as you’re suggesting, the behavior wouldn’t disappear on different devices or when side loaded.
I could easily be wrong, I just don’t see the behavior I’d expect to see for a wide ranging own like a repo takeover.
Yeah, I didn’t understand. Sorry about that.
I could potentially see this happing if it’s an app that this app talks to that’s compromised or perhaps if they have a second app installed that this app interfaces to/that is talking to this app to prompt this behavior.
It wasn’t clear to me if they attempted to duplicate this on the same hardware by wiping the device and then side loading the app/installing it from a different app store.
But I think that’s because this app is a stock app that can’t generally be deleted (only rolled back to a previous version) from my understanding. But I may be wrong about that. This definitely makes it sound like it was the most recent update that caused this behavior.
Yeah, it’s a bit confusingly worded. A couple paragraphs down it starts to show how the behavior isn’t consistent
Just the fact that the same version installed other ways didn’t have the same behavior makes an app compromise conclusion hard to support. But you’re entirely right that this could be secondary app caused, potentially the update mechanism on the phone was compromised, which might explain why side loading didn’t have the same behavior.