The critical AMP for WP vulnerability was a 2018 flaw that let any logged in user, even a subscriber, rewrite the plugin’s settings and plant scripts in them. It was fixed in version 0.9.97.20, which went live on November 13, 2018, after WordPress.org had paused the plugin for more than three weeks. The plugin has shipped a steady run of smaller security fixes since then, most recently in version 1.1.17 on September 10, 2026, so the practical answer is to update to the latest release and check that nobody used an old hole on your site.
wp plugin update accelerated-mobile-pages). If you ran anything older than 1.1.13, and especially a 2018 version below 0.9.97.20, audit your administrator accounts, the plugin’s settings and wp-content/uploads for injected code. If you only kept AMP for Google Top Stories, you can retire it: Google stopped requiring AMP there in 2021.This article is about AMP for WP, Accelerated Mobile Pages (plugin slug accelerated-mobile-pages), which the WordPress.org plugin page lists with more than 70,000 active installations. It is a different product from the plugin simply called AMP (slug amp). Every version and date below comes from the plugin changelog, the vendor’s own 2018 post, NVD, WPScan or Patchstack; where those sources disagree, we say so or leave the detail out.
The 2018 critical flaw: what happened
The problem sat in a function called ampforwp_save_steps_data, which saves settings from the plugin’s setup wizard. It was registered as the AJAX action wp_ajax_ampforwp_save_installer, and that hook runs for any logged in user. The function checked neither a nonce nor a capability such as manage_options, so a subscriber account was enough to change the plugin’s options, including fields that output HTML and JavaScript on every AMP page.
- October 20, 2018: WordPress plugin developer Sybre Waaijer, author of The SEO Framework, publicly reported the issues. WPScan dates its entry to that day and credits him, and the AMP for WP team credits him too.
- October 21, 2018: according to the vendor, the WordPress.org plugins team paused delivery of the plugin until the holes were fixed.
- November 13, 2018: the plugin returned in version 0.9.97.20, which added the missing nonce and capability checks. Security firm WebARX published a technical write up around the same time, and reports then put the install base above 100,000 sites.
- November 2018: Wordfence reported an active campaign exploiting the flaw on sites that had not updated. Attackers stored a script in the plugin settings; when an administrator opened the dashboard, the script created a rogue administrator named
supportuuser. - Late November 2018: version 0.9.97.21 added sanitization of user content before saving. NVD later assigned
CVE-2018-20838to it:ampforwp_save_steps_data“before 0.9.97.21” allows stored XSS.
Every later security fix at a glance
No later issue matched the 2018 bug for reach, but the list is long. The affected ranges below are NVD’s “up to and including” versions; the fix is the next release in the plugin changelog.
| NVD date | Issue | Who can exploit it | Affected | Fixed in | ID |
|---|---|---|---|---|---|
| Mar 2022 | Stored XSS in settings | Administrator | up to 1.0.77.32 | 1.0.77.33 | CVE-2021-23150, CVE-2021-23209 |
| Jan 2024 | Stored XSS via shortcode | Contributor | up to 1.0.92 | 1.0.92.1 | CVE-2023-6782 |
| Jan 2024 | Reflected XSS (disqus_name) | Anyone, if a user clicks a link | up to 1.0.92.1 | 1.0.93 | CVE-2024-0587 |
| Feb 2024 | Arbitrary post deletion | Contributor | up to 1.0.93.1 | 1.0.93.2 | CVE-2024-1043 |
| Jul 2024 | Stored XSS via SVG upload | Author | up to 1.0.96.1 | 1.0.97 | CVE-2024-6896 |
| Oct 2024 | CSRF that leaks admin cookies (rated 8.8, high) | Anyone, if an admin clicks a link | up to 1.0.99.1 | 1.0.99.2 | CVE-2024-9598 |
| Dec 2024 | Reflected XSS (disqus_name) | Anyone, if a user clicks a link | up to 1.1.1 | 1.1.2 | CVE-2024-11254 |
| Jan 2026 | CSRF on comment submission | Anyone, if a user clicks a link | up to 1.1.9 | 1.1.10 | CVE-2025-14468 |
| Jan 2026 | Stored XSS via SVG upload | Author | up to 1.1.10 | 1.1.11 | CVE-2026-0627 |
| Jul 2026 | Arbitrary file write via font ZIP upload | Author, if an admin granted plugin access | up to 1.1.12 | 1.1.13 | CVE-2026-6101 |
Two newer fixes appear only in the changelog so far: version 1.1.15 (July 24, 2026) fixed an Editor level stored XSS, and version 1.1.17 (September 10, 2026) fixed a stored XSS in how comment content is transformed. We found no NVD record for either when this was written. The pattern is familiar for a large plugin: shortcodes and SVG uploads that let lower roles inject script, AJAX handlers with broken nonce or capability checks, and one file upload path that could end in code execution. The most serious recent one, CVE-2026-6101, let an Author write arbitrary files through the local font feature, which can mean remote code execution on servers that run PHP from the uploads folder.
Check your version and update safely
Find the installed version
In the dashboard, open Plugins, then Installed Plugins, and find “AMP for WP, Accelerated Mobile Pages”; the version number sits under the description. With shell access, WP-CLI is faster and works across many sites:
wp plugin get accelerated-mobile-pages --field=version
wp plugin list --name=accelerated-mobile-pages --fields=name,status,version,update_version,auto_updateAn empty update_version means no newer release is available. Anything below 1.1.17 should be updated today.
Update without surprises
Take a backup first; our guide on how to back up a WordPress website manually covers files and database. Then update, confirm the files match the WordPress.org release, and turn on automatic updates for this plugin so the next fix arrives without you:
wp plugin update accelerated-mobile-pages
wp plugin verify-checksums accelerated-mobile-pages
wp plugin auto-updates enable accelerated-mobile-pagesIf you ran a vulnerable version: what to audit
Updating closes the hole but does not undo anything an attacker already did. Work through these checks, starting with the ones that match the versions you ran.
1. Administrator accounts
List every administrator and look for accounts you do not recognize, recent registration dates, or odd email domains. The 2018 campaign created supportuuser, but a later attacker could use any name.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered2. The plugin settings
AMP for WP keeps its main settings, through the Redux framework, in an option named redux_builder_amp. The 2018 payloads were written into the plugin’s options, so search that option and the rest of the options table for script tags; any custom code or analytics snippets you added yourself will show up too. Our explainer on where WordPress plugin settings are stored shows what else lives in that table.
wp option get redux_builder_amp --format=json | grep -io '<script[^>]*>'
wp db search '<script' wp_optionsIf your table prefix is not wp_, change the table name. For a direct SQL check, see how to run a database query in WordPress.
3. Files in uploads and code integrity
The CVE-2026-6101 bug could drop files into a web accessible folder, so look for PHP where only media should be, then verify core and plugin files against WordPress.org:
find wp-content/uploads -type f -name '*.php'
wp core verify-checksums
wp plugin verify-checksums --allPlugins that are not hosted on WordPress.org, such as premium ones, cannot be verified this way, which is normal. Also block PHP execution in wp-content/uploads at the web server level if your host allows it.
4. Access, passwords and sessions
The file write bug needed an administrator to have granted Authors access to the plugin, so review who besides administrators can open its settings and keep that list short. If anything above looked wrong, reset administrator passwords and run wp config shuffle-salts, which signs every user out.
Do you still need AMP in 2026?
Probably not for search visibility. Google announced in May 2020 that AMP would no longer be required for the Top Stories carousel on mobile, and that change arrived with the page experience update, which began rolling out in mid June 2021. Google’s documentation now says Search indexes AMP pages like any other page and applies the same standard regardless of the technology used. What AMP still costs you is a second version of every page to keep consistent, and a large plugin whose security history you have just read.
If you retire it, follow Google’s guide to removing AMP from your site: remove the rel="amphtml" link (deactivating the plugin does that), redirect each AMP URL to its canonical page with a 301, and watch the indexed AMP pages trend down in Search Console. AMP for WP uses an /amp/ endpoint by default, for example https://example.com/sample-post/amp/, although the endpoint name can be changed. For Apache, put this above the WordPress block in .htaccess:
RewriteEngine On
RewriteRule ^amp/?$ / [R=301,L]
RewriteRule ^(.+)/amp/?$ /$1/ [R=301,L]The Nginx equivalent goes in the server block:
rewrite ^/amp/?$ / permanent;
rewrite ^/(.+)/amp/?$ /$1/ permanent;Troubleshooting
The site breaks after the update
Deactivate the plugin with wp plugin deactivate accelerated-mobile-pages --skip-plugins, which stops WP-CLI from loading the broken code first. Without shell access, rename its folder in your host’s file manager, as described in how to disable a WordPress plugin from cPanel, then restore your backup or wait for a patch release.
Checksum verification reports modified files
Treat that as a possible compromise, not a glitch. Reinstall a clean copy with wp plugin install accelerated-mobile-pages --force, then run the audit steps above.
Old AMP URLs return 404 after removal
The redirect rules are missing or sit below the WordPress rules. Move them to the top of .htaccess, or check the Nginx block that serves the site, then request an old /amp/ URL and confirm the 301.
Frequently asked questions
Which AMP for WP version fixed the 2018 vulnerability?
Version 0.9.97.20, which WordPress.org made available again on November 13, 2018, added the missing nonce and capability checks to the setup wizard’s save function. Version 0.9.97.21, released later that month, added sanitization of saved content and is the fix referenced by CVE-2018-20838. Today you should run 1.1.17 or later.
Who discovered the AMP for WP flaw?
Plugin developer Sybre Waaijer reported the issues publicly on October 20, 2018, and both WPScan and the AMP for WP team credit him. Security firm WebARX published a technical analysis, and Wordfence documented the attack campaign that exploited unpatched sites. Most later fixes in the changelog credit Wordfence researchers, and at least one credits Patchstack.
Is AMP for WP safe to use in 2026?
The current release has fixes for every issue listed here, and in the recent cases the fix shipped before or right around public disclosure. Safe use still means automatic updates, limiting plugin access to administrators, and not letting untrusted users upload SVG files. If you no longer need AMP, removing the plugin removes the risk entirely.
Does deleting the plugin clean up a hacked site?
No. Deleting the plugin removes its code, but rogue administrator accounts, injected options in the database and files dropped into uploads all stay behind. Run the audit steps in this article, or restore a backup made before the compromise, and then change passwords and salts so stolen sessions stop working.
The bottom line
The 2018 AMP for WP flaw was fixed years ago, but the plugin has needed more than a dozen further security fixes since, including a file write bug patched in April 2026 and an XSS fix on September 10, 2026. Run 1.1.17 or later and keep automatic updates on.
If you ran an old version, spend twenty minutes on the audit: administrators, the redux_builder_amp option, PHP files in uploads and checksums. And ask whether you need AMP at all; for most sites in 2026, removing it with proper redirects is the safer and simpler choice.

