wordpress-develop

WordPress 7.1.3: Every Change Explained, Tested, and What to Do After You Update First published on LetsKnowTech, where I keep it up to date. WordPress 7.1.3 came out on October 6, 2026. It's a security and maintenance release with seven security fixes and four bug fixes, and it's the version every WordPress site should be on right now. WordPress.org already marks 7.1.0, 7.1.1 and 7.1.2 as insecure. It's a small, low-risk release, so update. Fifteen files change, the database doesn't, and a site on 7.1.2 downloads a 227 KB patch instead of the full 37 MB package. One change is visible to readers, though: Imgur embeds stop working, and old ones keep showing until you clear their cache. Below, every change in 7.1.3 is explained twice: once in plain words, and once for developers, with the file and function that changed. Everything in the "what we saw" parts comes from updating a real test site from 7.1.2 to 7.1.3 and checking each change before and after. WordPress 7.1.3 release details | | | |---|---| | Released | October 6, 2026 | | Type | Security and maintenance release (a "minor" release) | | Fixes | 7 security fixes, 4 bug fixes | | CVE IDs | One so far: CVE-2026-66666 (comments on private posts, CVSS 4.0 score 6.9, Medium) | | Known attacks | None reported for any of the seven (but the critical fix in 7.1.2, which 7.1.3 includes, is under active attack) | | Database change | None (database version stays 61833, so there's no "Update database" screen) | | Requirements | Unchanged: PHP 7.4 or newer, MySQL 5.5.5 or newer (7.1 compatibility; the same minimums are in version.php of both releases) | | Files changed | 15 in the release package, none added or removed | | Download size from 7.1.2 | 227 KB partial update instead of the 37.2 MB full package (the 15 changed files plus the updater and readme that every update package carries; measured October 12, 2026) | | Older versions | Security backports for every branch from 4.7 to 7.0, released the same day | | Next release | WordPress 7.2, scheduled for December 8, 2026 | The official announcement is on the WordPress.org news blog, and the full code diff is in the 7.1.2...7.1.3 comparison on GitHub. One correction if you read the official version page: its "List of files revised" isn't quite right. It names two Customizer files (class-wp-customize-manager.php and class-wp-customize-setting.php) that are byte-for-byte identical in the 7.1.2 and 7.1.3 downloads, and it leaves out wp-admin/includes/image.php, the toolbar stylesheets, about.php and version.php, which did change. You can see this in the GitHub comparison above, which never touches the Customizer files, or by comparing the two zips from the release archive yourself. We did both. The full list of changed files is in the developer section. Should you update? Is 7.1.3 stable? Yes, update. Three reasons: 1. It's a security release. WordPress recommends updating immediately, and the version API now marks every earlier 7.1 release as insecure. 2. The risk of breaking something is low. No database change, no new requirements, no bundled package updates, and the code changes are small. Most of the security patches change a handful of lines each. 3. If you're on 7.1.0 or 7.1.1, you're missing much more than these seven fixes. WordPress 7.1.2 fixed a critical flaw that could lead to remote code execution under some server setups, and that flaw is now being exploited. More on that below. None of the seven issues is a drop-everything emergency on its own. Two can be started by someone who isn't logged in, and both need something else to line up. The rest need a logged-in account or an unusual plugin setup. But the fixes are public, and the patch shows exactly where each weakness was, so the gap between "patched" and "someone tries it" gets shorter every day. How much each fix matters depends on how your site is used: | Your site | The fixes that matter most to you | |---|---| | A blog with open comments | The pending-comment fix on the Comments screen, and the private-post comment leak | | A site with writers (Contributors or Authors) | The Imgur embed fix, the link-preview slowdown fix, the sticky-post fix | | A site with private or draft posts that get comments | The private-post comment leak (CVE-2026-66666) | | A site where admins export content (Tools > Export) | The export fix | | A site with custom plugins that use custom post statuses | The status-hook change (read the developer notes) | | A simple brochure site with comments off and one admin | Little direct exposure, but update anyway: it's free and takes seconds | Is 7.1.3 stable? As of October 12, 2026, there are no reports of 7.1.3 breaking sites, and there's no 7.1.4 announced. The only change that visibly alters content is the Imgur one. The known WordPress 7.1 problems so far, and where each stands: - WP Rocket below 3.23.2.2 crashed sites on 7.1 with Uncaught TypeError: substr(): Argument #1 ($string) must be of type string, int given in .../wp-rocket/inc/ThirdParty/Plugins/CDN/Cloudflare.php:562. That's fixed in the plugin, not in WordPress: update WP Rocket to 3.23.2.2 or later (released August 20, 2026). - The toolbar site icon showing huge on some themes: fixed in 7.1.3. - Image uploads failing on hosts without PHP's DOM extension (a 7.0 bug): fixed in 7.1.3. If you run a lot of sites, test on one first. A copy of your site on your computer works fine for that; our WordPress localhost guide covers every way to set one up. The 7 security fixes, explained Here's the full list, with what an attacker would need for each one. "Contributor+" means anyone with the Contributor role or higher. | # | The fix | What an attacker needed | Reported by | |---|---|---|---| | 1 | Stored XSS on the Comments screen, through pending comments | A comment waiting for approval, and a moderator (Editor or Administrator) interacting with it | Trail of Bits, with OpenAI | | 2 | Denial of service in WP_Http::make_absolute_url() | A Contributor+ account | Anthropic | | 3 | Second-order SQL injection in the WXR export | A bad value already stored in the database, and an administrator running a specific export | Anthropic | | 4 | Authors could make posts sticky | An Author account | Anthropic | | 5 | Comments on private and unpublished posts readable without logging in (CVE-2026-66666) | Nothing: no account needed | Ananda Dhakal (Patchstack) | | 6 | XSS through Imgur embeds | A Contributor+ account, and someone viewing the post | Zhengyu Liu, Jingcheng Yang, Gavin Zhong | | 7 | Forgeable {status}_{type} hook names | A plugin that saves unchecked post statuses or post types | Alex Concha (WordPress security team) | The credits come from the release announcement: three of the seven reports came from Anthropic and one from Trail of Bits working with OpenAI. The 7.1.1 credits also name Anthropic (twice) and pwn.ai. Three security releases in 19 days is a fast pace for WordPress, and the security team is shipping fixes as reports arrive rather than holding them for one big release. A quick glossary for the terms below: - XSS (cross-site scripting): someone gets their own JavaScript to run in another person's browser on your site. If that person is an admin, the script can act as the admin. "Stored" means the script is saved in your database and waits there. - SQL injection: text an attacker controls ends up inside a database query and changes what the query does. "Second-order" means the bad value is stored first, looks harmless, and only causes trouble when WordPress reuses it later. - Denial of service (DoS): making the server spend its resources on something useless, so the site slows down or stops answering. 1. Stored XSS on the Comments screen (pending comments) In plain words: a comment waiting in your moderation queue could carry a booby-trapped link. If a moderator interacted with it on the Comments screen, script could run in the moderator's browser, with the moderator's permissions. Comments wait in that queue for exactly the people who can approve them, so the target is always a trusted user. Who was exposed: sites running 7.1.0 to 7.1.2 with comments on. Before 7.1, a visitor's comment couldn't carry the markup this needed. WordPress 7.1 started letting comments keep a class attribute on span tags, so @mentions in Notes (the comments you leave on blocks in the editor) display properly; that's _wp_kses_allow_note_mention_span() in kses.php. Older branches got the same hardening anyway. What changed in the code: the click handler for the contextual Help tabs in wp-admin/js/common.js passed a link's href straight to jQuery's $(). jQuery treats any string that looks like HTML as HTML to build, not as a selector to look up. 7.1.3 changes one line to $( document ).find( link.attr('href') ), and .find() only accepts selectors. What to do: update. If you have a big pending queue from before the update, it's fine to moderate it after updating; the patched handler no longer builds HTML from those links. 2. Denial of service in WP_Http::make_absolute_url() In plain words: WordPress has a helper that turns relative links (like ../image.png) into full addresses. Certain malformed paths sent it into a loop that never ended, tying up a server process. A logged-in writer could reach it through the editor's link previews, which fetch the page you're linking to. Who was exposed: sites with Contributor or higher accounts held by people you don't fully trust, such as open registration with writer roles or guest-post programs. What changed in the code: in wp-includes/class-wp-http.php, the loop that strips folder/../ pairs now counts how many replacements each pass made, and stops when a pass changes nothing. On older branches (before 5.9) the same class lives in class-http.php and got the same fix. We ran six ordinary relative URLs through the function on 7.1.2 and 7.1.3, and the results were identical, so normal link handling is unchanged. What to do: update. Review who has writer accounts while you're at it (see the checklist). 3. Second-order SQL injection in the WXR export In plain words: WordPress's export tool (Tools > Export) builds a list of featured-image IDs from each post's settings and drops them into a database query. It trusted that those IDs were numbers. If a non-number had already been stored there, through a buggy plugin or another weakness, the export could run an altered query when an administrator exported content. Who was exposed: two things had to line up: a bad _thumbnail_id value already sitting in your database, and an administrator exporting a single content type. The default "All content" export doesn't reach this code. The code itself dates from WordPress 6.5. What changed in the code: wp-admin/includes/export.php now runs absint() (force to a whole number of zero or more) on the thumbnail IDs, on the merged list of post IDs, and again right before each batch of 20 IDs goes into the WHERE ID IN (...) query. That's three layers for one bug, which is the security team being deliberately cautious. What to do: update. Exports keep working; a single-type export on our 7.1.3 test site completed normally. If you move content between sites often, our guide on exporting posts with their media and featured images still applies unchanged. 4. Authors could make posts sticky In plain words: a sticky post is pinned to the top of your blog's front page, and on default WordPress roles that's an Editor's decision. Through the REST API, an Author could pin their own posts anyway. Who was exposed: sites with Author accounts. The impact is mostly editorial: someone can push their post to the top of your home page. What changed in the code: in class-wp-rest-posts-controller.php, the sticky check refused a request only when the user lacked both edit_others_posts and publish_posts. Authors have publish_posts, so they passed. The fix changes "and" to "or": now a user missing either capability is refused. On updates, the check only runs when the request actually changes the sticky value. What we saw: Authors' editing screen doesn't change at all. The block editor never showed them the "Stick to the top of the blog" toggle, because the REST API's action-sticky link already required both capabilities, even in 7.1.2. On 7.1.3: - An Author setting sticky on their own post gets 403 rest_cannot_assign_sticky: Sorry, you are not allowed to make posts sticky. - An Editor can still make any post sticky. - An Author can still edit a post that an Editor made sticky (the save goes through and the post stays sticky). - An Author can't unstick it. What to do: nothing, unless you have a custom app or script that lets Authors pin posts. That will now fail with the error above. Have an Editor pin posts, rather than giving Authors edit_others_posts, which would let them edit everyone's posts. 5. Comments on private and unpublished posts readable without logging in (CVE-2026-66666) In plain words: every post has a comment feed (an RSS feed of its comments). For private or unpublished posts, WordPress loaded the comments before checking whether the visitor was allowed to see the post. It then hid the post, but the comments were already loaded, and the feed printed them for anyone who asked. Who was exposed: any site where private, draft or scheduled posts have comments. That's more common than it sounds: internal notes left as comments, client feedback on a draft, or comments left before a post was made private. It's tracked as CVE-2026-66666, rated 6.9 (Medium) on CVSS 4.0. The CVE record lists 6.6 through 7.1.2 as the affected versions. WordPress still shipped the same code change to every older branch down to 4.7, so a site on, say, 6.2 gets it as well, whether or not that branch could actually be attacked this way. It isn't in CISA's list of exploited vulnerabilities. What changed in the code: in wp-includes/class-wp-query.php, the 37-line block that queries a single post's comment feed moved below the post-status check in get_posts(). Nothing in it changed; it just runs after WordPress decides whether you can see the post. What we saw: on 7.1.3, a public post's comment feed still lists its comments, and a private post's feed returns no comments to a logged-out visitor. What to do: update. If private posts on your site hold sensitive comments, assume anything public-facing before the update could have been read, and judge whether that matters for you. 6. XSS through Imgur embeds In plain words: when you paste a link from YouTube, Spotify or another supported site, WordPress asks that site for the embed code. For a short list of trusted providers, WordPress inserts that code as it arrives. Everyone else's code is cut down to a sandboxed frame first. Imgur was on the trusted list, and its embed code includes text from the person who uploaded the image, so whatever that person wrote could end up on your page unfiltered. Who was exposed: sites where Contributors or higher can publish embeds, and the readers of those posts. What changed in the code: wp-includes/class-wp-oembed.php removes Imgur from the provider list. The file's own table of retired providers now lists Imgur as removed in 7.1.3, alongside Someecards (see the bug fixes). WordPress.org's Embeds help page still lists Imgur as supported; it hasn't caught up with the code yet. What we saw: this is the one change your readers will notice, so we tested it closely. - On 7.1.2, an imgur.com/a/... album link in an Embed block showed Imgur's full card, with its script loaded from Imgur. - After updating, the old card kept showing. WordPress stores embed code in the post's metadata, and the update doesn't touch it. It survived re-saving the post, and it survived even when we backdated the cache by ten days and re-saved. - After clearing the post's embed cache, the post showed the bare Imgur address as plain text: not an embed, and not even a clickable link. A plain Imgur URL on its own line in a classic-editor post did the same. - In the block editor, the Embed block now says "Sorry, this content could not be embedded." and offers Convert to link. - Links in the imgur.com/gallery/... form, which is what Imgur's address bar shows, already failed to embed on 7.1.2, because Imgur's own embed service no longer answers for them. !The block editor on WordPress 7.1.3 showing an Imgur Embed block with the message Sorry, this content could not be embedded, and two buttons: Try again and Convert to link An Imgur Embed block after the update. Convert to link turns it into a normal link readers can click. Imgur also cut off visitors from the UK in September 2025, so UK readers had already been seeing blank Imgur embeds. What to do: update, then clear the embed cache for posts that use Imgur and replace those embeds. The checklist has the exact steps. 7. Forgeable {status}_{type} hook names In plain words: when a post changes status (say, from draft to published), WordPress announces it to plugins with named "hooks" built from the status and post type, such as publish_post or draft_to_publish. Some unrelated core hooks follow the same naming pattern. If a plugin saved a post with a status nobody had registered, the generated name could match one of those unrelated hooks and set off code meant for something else entirely. Who was exposed: only sites with a plugin that passes unchecked statuses or post types into wp_insert_post(). Default WordPress doesn't. What changed in the code: wp_transition_post_status() in wp-includes/post.php now fires {$old_status}_to_{$new_status} only when the new status is registered and the old one is registered (or is new), and fires {$new_status}_{$post_type} only when the new status and the post type are both registered. The general transition_post_status hook still fires every time. What to do: site owners: just update. Developers: read the developer notes. This one can change how your plugin behaves. The 4 bug fixes Two of these fix problems people hit after updating to 7.0 or 7.1. The other two update WordPress's list of embed providers. Image uploads could fail with a fatal error (missing PHP DOM extension) WordPress 7.0 added a feature that reads alt text embedded in an image's metadata when you upload it. That code used PHP's DOM extension without checking it was installed. On hosts without it, uploading an image stopped with: PHP Fatal error: Uncaught Error: Class "DOMDocument" not found in .../wp-admin/includes/image.php WordPress lists the DOM extension as recommended, not required, and nearly every host has it, so this was rare. The code shipped in 7.0 and went 134 days before the first report (Trac #66221). For the sites it hit, though, it stopped all image uploads. In 7.1.3, wp_get_image_alttext() returns empty alt text when DOM isn't available, and the upload continues. To check whether your host has the extension, go to Tools > Site Health. If it's missing, Site Health shows "One or more recommended modules are missing". Ask your host to enable dom; other features use it too. Note that 7.0.7 doesn't include this fix. The 7.0 backport carries only the security fixes, so sites without the DOM extension need 7.1.3. The toolbar site icon could show up huge WordPress 7.1 added your site icon to the admin toolbar, sized with just a width and a height. Many themes and plugins have rules like img { width: auto !important; height: auto !important; }, which override those, so the icon rendered at the size of the image file and covered part of the page. People reported it on Divi and other themes (Trac #65912). 7.1.3 adds matching minimum and maximum sizes and a more specific selector (img.site-icon) in admin-bar.css. In our test with that exact theme rule, the icon measured 150 × 150 px on 7.1.2 and 20 × 20 px on 7.1.3 (28 × 28 px on a 390 px-wide phone screen). If you added custom CSS to work around this after 7.1, you can remove it now. ReverbNation embeds work again ReverbNation moved its site and embed service to legacy.reverbnation.com, and the old address returns "404 Not Found", so embeds of artist and song pages had stopped working (Trac #66079). On 7.1.2, a www.reverbnation.com/artist link didn't embed at all in our test. On 7.1.3 it embeds the player again. Links that already used legacy.reverbnation.com worked before through WordPress's generic embed support, and still do. Someecards embeds removed Someecards' embed service returns a 404, and its pages no longer advertise one, so 7.1.3 removes someecards.com and some.ly from the provider list (Trac #66078). Those links were already failing, so nothing that worked before breaks. The 7.1.3 tag also includes some changes that never reach your site: trimmed automated-test runs for the 7.1 branch, a database health check for WordPress's Docker development setup, a test fix, and new unit tests for the alt-text function. What we saw when we updated a test site To see what 7.1.3 changes in practice, we installed WordPress 7.1.2 from the official download on a fresh test site, recorded how it behaved, updated it to 7.1.3 with WP-CLI, and ran the same checks again. The test site used PHP 8.2 and MariaDB 10.4 with the default theme, plus one extra rule that forces every image to its natural size, as some themes do. !The same test page before and after the update. On WordPress 7.1.2 the toolbar site icon is 150 pixels wide and an Imgur album shows as a full embed card. On WordPress 7.1.3 the icon is 20 pixels and the Imgur link shows as plain text. The same post before and after the update, with the embed cache cleared: the toolbar icon is back to 20 px, and the Imgur album is now plain text. | What we checked | 7.1.2 | 7.1.3 | |---|---|---| | The update itself | — | Downloaded the 227 KB partial package; no database update needed; core checksums verified | | Imgur album in an Embed block | Full Imgur card, script from Imgur | Cached card keeps showing until the embed cache is cleared, then plain text | | Toolbar site icon under a "natural size" theme rule | 150 × 150 px | 20 × 20 px (28 × 28 px on phones) | | Author pins own post via the REST API | — | Refused (403) | | Author edits a post an Editor pinned | — | Works, stays pinned | | Post moved to a status nobody registered | Both dynamic status hooks fire | Neither fires; transition_post_status still does | | Publishing a post whose type isn't registered | new_to_publish and publish_book fire | Only new_to_publish fires | | ReverbNation www artist link | No embed | Embeds | | Relative-URL resolution (6 normal cases) | — | Identical to 7.1.2 | | Public post comment feed | — | Works | | Single-type export | — | Works | Nothing else on the test site changed. The one change you'll see on a real site is the Imgur one, and only once the cache is cleared. For developers: what could affect your code Most of 7.1.3 is invisible to plugin and theme code. Five changes are worth checking. 1. Dynamic status hooks need registered statuses and post types. If your plugin stores posts with a custom status like in_review but never calls register_post_status(), hooks like draft_to_in_review and in_review_post no longer fire. The same goes for {status}_{type} when your post type isn't registered at the moment the status changes, for example while your plugin is inactive or if it registers the type late. In our test, the same transition fired both hooks again as soon as the status was registered. The fix: add_action( 'init', function () { register_post_status( 'in_review', array( 'label' => _x( 'In review', 'post status', 'my-plugin' ), 'public' => false, 'internal' => false, 'show_in_admin_status_list' => true, 'label_count' => _n_noop( 'In review <span class="count">(%s)</span>', 'In review <span class="count">(%s)</span>', 'my-plugin' ), ) ); } ); If you can't register the status, listen on transition_post_status instead. It still fires for every change and passes the new status, the old status and the post: add_action( 'transition_post_status', function ( $new_status, $old_status, $post ) { if ( 'in_review' === $new_status && 'in_review' !== $old_status ) { // Same job your draft_to_in_review callback used to do. } }, 10, 3 ); 2. The REST sticky check is stricter. Changing sticky now needs both edit_others_posts and publish_posts. If your app sends the whole post object back on save, it's fine: on updates, a sticky value that matches the post's current state isn't checked. If it sends sticky: true on create for Author-level users, expect rest_cannot_assign_sticky. 3. Imgur is no longer a built-in oEmbed provider. wp_oembed_get() returns false for Imgur URLs, and the editor's /oembed/1.0/proxy endpoint returns 404 oembed_invalid_url. Don't re-add Imgur with wp_oembed_add_provider() as a trusted provider; that's the exact hole that was closed. Cached results stay in _oembed_* post meta and oembed_cache posts until cleared. On the front end, WordPress serves post-meta embed caches without checking their age, so they never refresh on their own. 4. Help-tab links are treated as selectors. The handler in common.js now uses $( document ).find( href ). If your plugin adds contextual Help tabs with WP_Screen::add_help_tab(), nothing changes; the generated #tab-panel-… links are plain ID selectors. 5. Comment-feed queries run later in WP_Query::get_posts(). The comment_feed_join, comment_feed_where, comment_feed_groupby, comment_feed_orderby and comment_feed_limits filters now run after the single-post status check instead of before it, with the same arguments. For a post the visitor isn't allowed to see, they no longer run at all. If you use those filters to log or count comment-feed requests, expect fewer calls. Also changed but behavior-neutral for valid input: WP_Http::make_absolute_url() stops its cleanup loop when a pass changes nothing, and export_wp() casts every post ID with absint(). Every file 7.1.3 changes These are all 15 files that differ between the 7.1.2 and 7.1.3 downloads. Nothing was added or removed. | File | What changed | |---|---| | wp-admin/js/common.js and common.min.js | Help-tab click handler uses $( document ).find() (fix 1) | | wp-includes/class-wp-http.php | make_absolute_url() loop exits when nothing is replaced (fix 2) | | wp-admin/includes/export.php | absint() on thumbnail IDs, merged IDs and each query batch (fix 3) | | wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php | Sticky check needs both capabilities; on update, only when the value changes (fix 4) | | wp-includes/class-wp-query.php | Comment-feed query moved after the post-status check (fix 5) | | wp-includes/class-wp-oembed.php | Imgur and Someecards removed, ReverbNation endpoint moved to legacy.reverbnation.com (fix 6 and two bug fixes) | | wp-includes/post.php | Dynamic status hooks fire only for registered statuses and post types (fix 7) | | wp-admin/includes/image.php | wp_get_image_alttext() returns early without DOMDocument (bug fix) | | wp-includes/css/admin-bar.css, admin-bar.min.css, admin-bar-rtl.css, admin-bar-rtl.min.css | Toolbar site icon gets min/max sizes and an img.site-icon selector (bug fix) | | wp-admin/about.php | "Maintenance and Security Releases" note for 7.1.3 | | wp-includes/version.php | $wp_version = '7.1.3' | Still on 7.1.0, 7.1.1 or 7.1.2? What you're missing 7.1.3 is the third security release since WordPress 7.1 "Mary Lou" came out on August 19, 2026. Updates are cumulative, so updating to 7.1.3 gets you everything below. | Release | Date | What it fixed | |---|---|---| | 7.1.1 | Sep 17, 2026 | 11 security fixes, 17 core bug fixes and 19 block editor bug fixes | | 7.1.2 | Sep 22, 2026 | 1 critical security fix (CVE-2026-87902) | | 7.1.3 | Oct 6, 2026 | 7 security fixes, 4 bug fixes | That's 19 security fixes in three releases. If you're on 7.1.2, you need only the seven fixes on this page. Your update is a 227 KB download. If you're on 7.1.1, you're also missing the 7.1.2 fix, and that's the serious one. CVE-2026-87902 let a visitor who isn't logged in make WordPress load a PHP file from outside the theme folder when it picks a page template. With the right server and theme conditions, that becomes remote code execution: an attacker running their own code on your server. WordPress rated it critical (9.2 on CVSS 4.0). And it's being used: the US Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog (search for CVE-2026-87902) on September 25, 2026, three days after the fix, which means there's evidence of real attacks. Your update is 236 KB. If a site of yours sat on 7.1.0 or 7.1.1 after late September, don't stop at updating. Check it for signs of a break-in: admin accounts you don't recognize, PHP files in wp-content/uploads, and core files that fail wp core verify-checksums. Our security checklist has the full clean-up order if you find something. If you're still on 7.1.0, you're missing all 19, including a stored XSS that a visitor could plant through a comment (fixed in 7.1.1). Your partial update is about 9 MB, because it also carries 7.1.1's bug fixes. If a site has been stuck on an old 7.1 release, check why. Usually it's automatic updates being off, a host that holds updates back, or wp-config.php settings such as AUTOMATIC_UPDATER_DISABLED or DISALLOW_FILE_MODS. Our WordPress security checklist covers how to set automatic updates so security releases arrive on their own. Older WordPress versions and backports Only the newest WordPress version is actively supported. As a courtesy, the security team backports security fixes to older branches, currently all the way back to 4.7. The 7.1.3 backports all shipped on October 6, 2026, the same day as 7.1.3. The announcement said they were "in progress" when it went out, but every branch has its release now. We checked each branch's code changes to see which fixes it actually received: | If you're on… | Update to… | Security fixes included | |---|---|---| | 7.0.x | 7.0.7 | All 7 (but none of the 4 bug fixes) | | 6.9.x | 6.9.10 | All 7 | | 6.8.x | 6.8.11 | All 7 | | 6.7.x | 6.7.10 | All 7 | | 6.6.x | 6.6.10 | All 7 | | 6.5.x | 6.5.13 | All 7 | | 6.4.x down to 4.7.x | 6.4.13, 6.3.13, 6.2.14, 6.1.15, 6.0.17, 5.9.19, 5.8.18, 5.7.20, 5.6.22, 5.5.23, 5.4.24, 5.3.26, 5.2.29, 5.1.27, 5.0.30, 4.9.34, 4.8.33, 4.7.38 | 6 of 7: the export fix isn't needed, because that code arrived in 6.5 | The full list of downloads is in the WordPress release archive. A backport keeps an old branch from being trivially attackable, but that's all it does. Old branches don't get bug fixes, many plugins stop testing against them, and the older the branch, the older the PHP it was built for. If you're on 6.x or older, plan the move to 7.1 instead of relying on courtesy patches. Moving from 7.0 (or older) to 7.1? That's a feature update, not just a patch, so test it on a copy first. According to the WordPress 7.1 Field Guide, the changes most likely to affect existing sites are these: - The post editor now always runs in an iframe, even when plugins add old-style meta boxes. Check plugins that add boxes, styles or scripts to the editor. - jQuery UI is updated to 1.14.2. Check plugins that use jQuery UI widgets such as date pickers, sliders and dialogs. - The toolbar now stays available on editor screens. Check plugins that add toolbar items. - Some image processing can now happen in the browser before upload. Check image-optimization and upload plugins. How to update to 7.1.3 Take a backup first, or confirm your host's backup from today exists. Then pick whichever fits. Automatically. Minor and security releases like this one install by themselves unless something turned that off. Go to Dashboard > Updates. If it says you have the latest version, you're done. The footer of any admin page and Tools > Site Health > Info > WordPress also show the version. From the dashboard. Dashboard > Updates > Update to version 7.1.3. It takes a few seconds. There's no database update step this time. With WP-CLI. Over SSH: wp core version # what you're on now wp core update # updates to 7.1.3 wp core verify-checksums # confirms every core file matches WordPress.org's copy On our test site, wp core update fetched wordpress-7.1.3-partial-2.zip (the 227 KB patch for 7.1.2), and wp core update-db confirmed the database was already current. Many sites at once. If you manage dozens of sites, use your management dashboard's bulk update, or loop WP-CLI over your sites with wp core update and wp core verify-checksums, then spot-check a few home pages. With three releases in 19 days, this is the month to set that up if you haven't. Manually. Download WordPress 7.1.3, replace the wp-admin and wp-includes folders and the root PHP files, and leave wp-content and wp-config.php alone. You won't need this unless automatic updates fail on your host. Rolling back. If something breaks, go back to 7.1.2 only for as long as it takes to fix the cause. You'd be reopening all seven holes. After you update: a 10-minute checklist 1. Confirm the version. Dashboard > Updates should say 7.1.3 (or wp core version). 2. Verify core files. wp core verify-checksums should report success. A failure means a core file differs from WordPress.org's copy; find out why before moving on. 3. Find posts that use Imgur. In Posts > All Posts, search for imgur.com (do the same under Pages). With WP-CLI: wp post list --s=imgur.com --post_type=any --fields=ID,post_title 4. Clear their embed cache. Re-saving the post doesn't do it; we tested that. Use WP-CLI: for id in $(wp post list --s=imgur.com --post_type=any --format=ids); do wp embed cache clear $id; done No WP-CLI? Open the post and replace the Imgur Embed block (next step). Once the Imgur address is no longer in the post, the cached code is never used again. 5. Replace the Imgur embeds. If the image is yours or you have permission, upload it to your Media Library and use an Image block. Otherwise, use Convert to link on the Embed block, so readers get a working link instead of a bare address. 6. Purge your page cache and CDN. Caching plugins and CDNs can keep serving the old Imgur card even after WordPress has dropped it. 7. Review writer accounts. Three of the fixes involve Contributors and Authors. List them under Users (filter by role), or with: wp user list --role__in=author,contributor --fields=user_login,user_email,roles Remove accounts nobody uses, and keep open registration on the Subscriber role. 8. Check Site Health. Tools > Site Health will flag a missing DOM extension and other problems worth fixing. 9. If you build plugins, search your code for register_post_status and for hooks shaped like *_to_* or {status}_{post_type}, and run your tests against 7.1.3 (see developer notes). 10. Delete custom CSS that shrank the toolbar icon after 7.1, if you added any. It's not needed now. What comes next WordPress 7.2 is scheduled for December 8, 2026, according to the release party schedule on the core team's blog. No 7.1.4 had been announced as of October 12. Given the pace of September and October, more 7.1.x security releases before 7.2 wouldn't be surprising. The practical defense is the same as always: leave automatic minor updates on, keep a recent backup, and follow the WordPress releases feed so you hear about the next one on the day it ships. FAQ What is the latest version of WordPress? WordPress 7.1.3, released October 6, 2026. WordPress.org's version check marks it as the latest and every earlier 7.1 release as insecure. Is WordPress 7.1.3 safe to install? Yes. It's a small security release with no database changes and no new requirements. The only visible change in our test was that Imgur embeds stop working. Is WordPress 7.1 stable? 7.1 itself has had three security releases and plenty of bug fixes since August. On 7.1.3, there are no known regressions as of October 12, 2026. If you held back from 7.1 because of early issues like the oversized toolbar icon or the upload error on hosts without the DOM extension, both are fixed in 7.1.3. If you use WP Rocket, make sure it's on 3.23.2.2 or later before moving to 7.1. Will 7.1.3 break my plugins or theme? Very unlikely. The changes that could affect code are narrow: plugins that use unregistered custom post statuses, apps that let Authors set sticky posts through the REST API, and anything that depends on Imgur embeds. See the developer notes. Why did my Imgur embeds stop working? WordPress 7.1.3 removed Imgur from its trusted embed providers to close an XSS hole. Old embeds keep showing until their cache is cleared, then they show as plain text. Replace them with uploaded images or links (steps). Is anyone exploiting these vulnerabilities? No exploitation has been reported for any of the seven, and the one with a CVE (CVE-2026-66666) isn't on CISA's Known Exploited Vulnerabilities list. The critical flaw fixed two weeks earlier in 7.1.2 (CVE-2026-87902) is on that list, though, so sites still on 7.1.0 or 7.1.1 are the ones at real risk. What are the CVE numbers for WordPress 7.1.3? So far only CVE-2026-66666, for the comments on private posts. The other six don't have CVE IDs or GitHub security advisories yet. Advisories for 7.1.1 appeared the day after that release, so these may follow. Do I need to update if I'm on WordPress 7.0? You should at least be on 7.0.7, which has all seven security fixes. But 7.0.7 doesn't have the bug fixes, and 7.0 only gets security fixes now, so moving to 7.1.3 is the better choice. Does 7.1.3 change the database? No. The database version stays 61833, so you won't see an "Update database" screen. How big is the 7.1.3 update? From 7.1.2 it's a 227 KB partial update: the 15 changed files, plus the updater and readme that every update package carries. From 7.1.1 it's 236 KB. From 7.1.0 it's about 9 MB. A fresh download is 37.2 MB. When is WordPress 7.2 coming out? It's scheduled for December 8, 2026. --- Written with AI assistance from my own test notes; the fixes were run on real WordPress installs before publishing.

Sécuriser WordPress : la checklist priorisée en 15 mesures (2026) L'essentiel en une minute Pour sécuriser WordPress, la priorité n'est pas l'extension de sécurité : ce sont les extensions tout court. Selon le rapport annuel de Patchstack, 91 % des nouvelles vulnérabilités recensées en 2025 dans l'écosystème WordPress se trouvaient dans des extensions, et seulement 6 dans le cœur du logiciel. Le travail utile porte donc sur ce que vous installez, sur les comptes qui peuvent l'administrer et sur votre capacité à revenir en arrière. Ce guide de sécurité WordPress classe 15 mesures par risque couvert et par effort. Les extraits de code viennent de la documentation officielle, consultée les 1er et 2 novembre 2026, avec les précautions qui évitent de casser le site. C'est une synthèse de sources publiques : nous n'avons testé aucun réglage sur un site en production. > Points clés > > - Patchstack, un éditeur de solutions de sécurité, a recensé 11 334 nouvelles vulnérabilités WordPress en 2025 : 91 % dans des extensions, 9 % dans des thèmes, 6 dans le cœur. > - Selon le même éditeur, 46 % de ces failles n'avaient pas de correctif au moment de leur divulgation : supprimer une extension inutile protège mieux que d'attendre. > - WordPress n'intègre pas la double authentification : la documentation officielle renvoie vers une extension ou un fournisseur d'identité. > - Chaque réglage de serveur se teste d'abord sur une copie, avec un accès SFTP ou SSH prêt pour revenir en arrière. > - Une sauvegarde n'existe que si sa restauration a été testée. L'ANSSI recommande la règle 3-2-1, avec une copie hors ligne. --- D'où viennent vraiment les failles WordPress Le cœur de WordPress est rarement en cause ; l'écosystème qui l'entoure l'est presque toujours. Le rapport « State of WordPress Security in 2026 » de Patchstack (page mise à jour le 25 février 2026) compte 11 334 nouvelles vulnérabilités en 2025, soit 42 % de plus qu'en 2024. Il en situe 91 % dans des extensions et 9 % dans des thèmes, avec seulement 6 failles dans le cœur, toutes de faible priorité. !Graphique en anneau : pour sécuriser WordPress, viser d'abord les extensions, qui concentrent 91 % des 11 334 vulnérabilités recensées par Patchstack en 2025, contre 9 % pour les thèmes et 6 failles dans le cœur Ces chiffres viennent d'un éditeur qui vend une protection contre ces failles et ne couvrent que celles qu'il a recensées. La cible est vaste : selon W3Techs, WordPress équipe 39,5 % de l'ensemble des sites web au 2 novembre 2026. Le même rapport explique pourquoi la mise à jour seule ne suffit pas. Selon Patchstack, 46 % des failles n'avaient pas reçu de correctif du développeur au moment de leur divulgation publique. 36 % (4 124) étaient assez graves pour justifier une règle de protection, et 17 % (1 966) présentaient une gravité élevée, propice aux attaques automatisées de masse. !Graphique en barres : sur les 11 334 vulnérabilités WordPress de 2025, 46 % sans correctif à la divulgation, 36 % assez graves pour une règle de protection, 17 % de gravité élevée, selon Patchstack Les composants payants ne sont pas plus sûrs. Sur une autre base, celle des signalements reçus, Patchstack compte 1 983 signalements valides visant des extensions ou thèmes premium ou freemium, soit 29 % des signalements, et en juge 76 % exploitables. Le délai d'attaque est court : environ la moitié des failles à fort impact ont été exploitées dans les 24 heures, et pour les plus ciblées, la médiane pondérée par l'intensité des attaques est de 5 heures. Notre panorama des cyberattaques les plus fréquentes situe ces menaces dans le contexte général. --- Sécuriser WordPress : le tableau des priorités Commencez par le haut : les premières lignes couvrent les risques les plus fréquents pour un effort faible. Le classement est le nôtre, fondé sur les sources citées dans chaque section. | Priorité | Action | Risque couvert | Effort | Section | |---|---|---|---|---| | 1 | Mises à jour automatiques du cœur, des extensions et des thèmes de confiance | Failles connues et corrigées | Faible | 1 | | 2 | Supprimer extensions et thèmes inutilisés ou abandonnés | Failles sans correctif | Faible | 2 | | 3 | Double authentification pour tous les administrateurs | Vol de mot de passe, phishing | Faible | 4 | | 4 | Mots de passe longs et uniques, gérés par un gestionnaire | Force brute, réutilisation | Faible | 3 | | 5 | Sauvegardes 3-2-1 et test de restauration | Rançongiciel, suppression, erreur | Moyen | 8 | | 6 | Pas de compte « admin », peu d'administrateurs, moindre privilège | Prise de contrôle complète | Faible | 3 | | 7 | Limiter les tentatives de connexion, protéger xmlrpc.php | Force brute | Faible à moyen | 4 | | 8 | DISALLOW_FILE_EDIT dans wp-config.php | Code injecté depuis l'admin | Faible | 6 | | 9 | Débogage désactivé en production | Fuite d'informations | Faible | 6 | | 10 | Clés et salages uniques | Vol de cookies de session | Faible | 6 | | 11 | HTTPS partout et en-têtes de sécurité | Interception, clickjacking | Moyen | 7 | | 12 | Permissions de fichiers adaptées, SFTP | Écriture de fichiers malveillants | Moyen | 6 | | 13 | API REST, pages auteurs et mots de passe d'application maîtrisés | Énumération, accès d'intégration | Moyen | 5 | | 14 | Pare-feu applicatif (WAF) ou CDN en amont | Exploitation de masse, bots | Moyen | 9 | | 15 | Journaux et surveillance des fichiers | Détection tardive | Moyen à élevé | 9 | Où coller les extraits. Les constantes se placent dans wp-config.php, au-dessus de la ligne « That's all, stop editing! », comme dans les exemples de la page officielle ; si la constante existe déjà, par exemple WP_DEBUG, modifiez la ligne existante au lieu d'en ajouter une seconde. Les filtres PHP vont dans une extension « must-use » du dossier wp-content/mu-plugins, chargée automatiquement, ou dans un thème enfant. Gardez toujours un accès SFTP ou SSH pour retirer une ligne qui bloque le site. --- 1. Les mises à jour, sans exception Mettre à jour reste la première mesure pour sécuriser WordPress, à condition de l'automatiser. Le manuel officiel « Hardening WordPress » rappelle que les mises à jour automatiques existent depuis la version 3.7. Pour le cœur, la page officielle Editing wp-config.php indique que les mises à jour mineures, celles de maintenance et de sécurité, sont appliquées par défaut. Pour les versions majeures, l'écran Tableau de bord, puis Mises à jour, propose un lien pour les automatiser. La constante WP_AUTO_UPDATE_CORE fait la même chose depuis wp-config.php : define( 'WP_AUTO_UPDATE_CORE', true ); La valeur 'minor' correspond au réglage par défaut ; false coupe toutes les mises à jour du cœur. D'après le code de l'écran des mises à jour, dès que cette constante est définie, elle prend le pas sur le réglage de l'interface, qui n'est plus modifiable. Pour les extensions et les thèmes, la documentation Plugin and themes auto-updates précise que depuis WordPress 5.5, l'administrateur les active extension par extension, dans une colonne dédiée de l'écran Extensions, et thème par thème. La même page suggère de s'assurer, avant de les activer, qu'un retour en arrière est possible. Face à des exploitations qui démarrent en quelques heures, une mise à jour manuelle hebdomadaire arrive souvent trop tard. --- 2. Moins d'extensions, de meilleures sources Chaque extension active est du code tiers exécuté sur votre serveur. Le manuel officiel demande de garder les extensions à jour, de supprimer celles que vous n'utilisez pas et de ne les obtenir que de sources fiables, comme le répertoire WordPress.org ou des sociétés reconnues. Désactiver ne suffit pas : supprimez. Face à une faille que son auteur ne corrige pas, une extension désinstallée reste la protection la plus sûre. Avant d'installer, vérifiez la date de dernière mise à jour sur la page du répertoire, et n'utilisez jamais une copie « nulled » d'une extension premium. Le même raisonnement vaut pour les thèmes inutilisés. --- 3. Des comptes administrateurs solides Un compte administrateur compromis donne tout le site. La page officielle Brute Force Attacks recommande de ne pas utiliser l'identifiant « admin », de limiter le nombre d'administrateurs et d'appliquer le moindre privilège au quotidien, par exemple avec un compte Éditeur pour publier. Côté mots de passe, le manuel « Hardening WordPress » écarte les mots du dictionnaire, les mots de passe courts et ceux qui reprennent votre nom ou celui du site. Un gestionnaire évite en plus la réutilisation : notre comparatif de gestionnaire de mot de passe gratuit aide à en choisir un. Supprimez aussi les comptes d'anciens prestataires et de test : le phishing vise précisément les identifiants d'administration. --- 4. Double authentification et tentatives de connexion Avec la double authentification, un mot de passe volé ne suffit plus à lui seul pour se connecter, mais WordPress ne l'intègre pas. La page officielle Brute Force Attacks le dit explicitement : activez la 2FA pour tous les administrateurs, via une extension ou votre fournisseur d'identité, car le cœur de WordPress ne l'inclut pas. L'extension Two Factor, publiée par le compte WordPress.org, propose une application d'authentification (TOTP), des codes par e-mail et des codes de secours. Préférez l'application : un code par e-mail relève de la validation en deux étapes selon la CNIL, comme l'explique notre guide de la double authentification. Générez et rangez les codes de secours avant tout, pour ne pas vous enfermer dehors si le téléphone est perdu. Pour la force brute, la même page recommande de limiter les tentatives de préférence en amont (pare-feu, CDN ou serveur web), car une extension s'exécute dans PHP et consomme des ressources pendant une attaque. Son exemple Nginx : # Define a shared zone for rate limiting limit_req_zone $binary_remote_addr zone=logins:10m rate=10r/m; server { # ... location = /wp-login.php { limit_req zone=logins burst=20 nodelay; include fastcgi_params; # pass to PHP-FPM or upstream as usual } location = /xmlrpc.php { limit_req zone=logins burst=20 nodelay; include fastcgi_params; # pass to PHP-FPM or upstream as usual } } Ne le collez pas tel quel. Selon la documentation de Nginx, une location exacte (=) arrête la recherche : ces deux blocs doivent donc reprendre vos directives PHP habituelles (fastcgi_pass, SCRIPT_FILENAME), à la place du commentaire, sinon la connexion casse. Derrière un CDN ou un proxy, $binary_remote_addr vaut l'adresse du proxy : configurez d'abord le module realip. Vérifiez avec nginx -t avant de recharger, et testez sur une copie, comme le demande la page officielle. Le fichier xmlrpc.php, cible fréquente, se désactive si vous ne l'utilisez pas ; sinon, restreignez-le, car Jetpack ou les applications mobiles peuvent en dépendre. --- 5. L'API REST, les auteurs et les mots de passe d'application L'API REST est active par défaut, et c'est voulu : la FAQ officielle de l'API REST déconseille de la désactiver, car l'administration de WordPress en dépend. Mieux vaut savoir ce qu'elle expose et le restreindre. Le cas classique est l'énumération des utilisateurs. La référence de l'endpoint Users montre qu'une requête sur /wp-json/wp/v2/users dans le contexte public view renvoie notamment l'identifiant numérique, le nom affiché, le slug et le lien de la page auteur. L'identifiant de connexion et l'adresse e-mail ne sont exposés que dans le contexte edit. D'après le code du contrôleur, un visiteur anonyme ne voit que les auteurs qui ont publié des contenus. Or le code de wp_insert_user() construit par défaut ce slug à partir de l'identifiant de connexion : la liste publique livre donc souvent la moitié du couple identifiant et mot de passe. Les pages auteurs font de même : selon le code de redirect_canonical(), une adresse /?author=1 redirige vers /author/<slug>/ si l'auteur a publié. Deux façons de limiter l'exposition : - Publier avec un compte distinct du compte d'administration. Cela couvre l'API comme les pages auteurs. Pour un compte existant, la commande WP-CLI wp user update accepte l'option --user_nicename, qui change ce slug. Réattribuez aussi à ce compte les contenus déjà publiés par l'administrateur, sinon celui-ci reste visible ; les liens vers l'ancienne page auteur cesseront alors de fonctionner. - Exiger l'authentification pour toute l'API, avec le filtre ci-dessous, documenté par la FAQ officielle. add_filter( 'rest_authentication_errors', function( $result ) { // If a previous authentication check was applied, // pass that result along without modification. if ( true === $result || is_wp_error( $result ) ) { return $result; } // No authentication has been performed yet. // Return an error if user is not logged in. if ( ! is_user_logged_in() ) { return new WP_Error( 'rest_not_logged_in', __( 'You are not currently logged in.' ), array( 'status' => 401 ) ); } // Our custom authentication check should have no effect // on logged-in requests return $result; }); Ce filtre coupe aussi l'accès anonyme aux articles via l'API : un site « headless » ou une extension qui lit vos contenus sans compte cesserait de fonctionner. Testez-le d'abord sur une copie. Les mots de passe d'application, présents depuis WordPress 5.6 selon la page Authentication, servent aux intégrations. Le guide d'intégration officiel indique qu'ils sont disponibles par défaut sur les sites en HTTPS et révocables depuis l'écran de l'utilisateur. Ce filtre les coupe entièrement, ce qui casse les intégrations qui en dépendent : add_filter( 'wp_is_application_passwords_available', '__return_false' ); Le filtre wp_is_application_passwords_available_for_user permet plutôt de les réserver aux administrateurs, selon le même guide. --- 6. Durcir wp-config.php et les permissions Le fichier wp-config.php contient les accès à la base de données. Les constantes ci-dessous viennent de la page officielle Editing wp-config.php et du manuel Hardening WordPress. Copiez le fichier avant toute modification. Désactiver l'éditeur de fichiers. Avec un compte administrateur volé, l'éditeur intégré permet d'injecter du code PHP : define( 'DISALLOW_FILE_EDIT', true ); Le manuel précise que cette ligne n'empêche pas l'envoi de fichiers malveillants, mais peut arrêter certaines attaques. La constante DISALLOW_FILE_MODS va plus loin : elle bloque l'installation et la mise à jour des extensions et des thèmes depuis l'administration. Attention : selon le code de WP_Automatic_Updater::is_disabled(), elle désactive aussi toutes les mises à jour automatiques, y compris les correctifs de sécurité du cœur. Réservez-la aux sites dont les mises à jour passent par un déploiement régulier. Clés et salages uniques. Les huit constantes AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs équivalents _SALT doivent être longues et aléatoires. La documentation de wp-config.php renvoie vers le générateur officiel et précise qu'on peut les changer à tout moment pour invalider tous les cookies existants : tous les utilisateurs devront se reconnecter. Remplacez les huit lignes existantes, sans les dupliquer. Débogage coupé en production. Afficher les erreurs PHP révèle des chemins et des versions. Configuration de production de la page officielle, qui remplace les lignes WP_DEBUG existantes : @ini_set( 'log_errors', 'On' ); @ini_set( 'display_errors', 'Off' ); define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false ); // 5.2 and later define( 'WP_DEBUG', false ); define( 'WP_DEBUG_LOG', false ); define( 'WP_DEBUG_DISPLAY', false ); HTTPS pour l'administration. La constante FORCE_SSL_ADMIN force les connexions et l'administration en HTTPS. Elle est superflue si l'adresse du site est déjà en https://. Derrière un proxy ou un CDN qui termine le HTTPS, la page officielle HTTPS prévient qu'elle provoque une boucle de redirection infinie, et donne ce correctif, qui suppose un proxy configuré pour transmettre l'en-tête X-Forwarded-Proto : define( 'FORCE_SSL_ADMIN', true ); // in some setups HTTP_X_FORWARDED_PROTO might contain // a comma-separated list e.g. http,https // so check for https existence if( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false ) $_SERVER['HTTPS'] = 'on'; N'utilisez ce correctif que si le serveur n'est joignable qu'à travers ce proxy, car n'importe quel client peut envoyer cet en-tête. En cas de boucle, retirez la constante par SFTP. Permissions de fichiers. Le manuel Hardening WordPress recommande 755 pour les dossiers et 644 pour les fichiers, avec ces commandes à adapter à votre chemin d'installation : find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \; find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \; Ces commandes ne changent pas le propriétaire : vérifiez d'abord sous quel utilisateur tourne PHP et à qui appartiennent les fichiers, sinon les mises à jour peuvent échouer. Pour wp-config.php, le manuel demande que seuls vous et le serveur web puissiez le lire, « ce qui signifie généralement 400 ou 440 » (notre traduction). Appliquez ce réglage après les commandes find, et seulement si PHP s'exécute sous le propriétaire du fichier (400) ou dans son groupe (440) : sinon PHP ne peut plus lire le fichier et le site tombe. Sur un hébergement mutualisé, demandez à l'hébergeur. Notre guide des commandes Linux de base explique chmod et find. Le manuel recommande aussi SFTP plutôt que FTP. --- 7. HTTPS et en-têtes de sécurité HTTPS est le minimum : il chiffre les échanges, dont les cookies de session. Les en-têtes de sécurité ajoutent une protection côté navigateur. Le tableau part de l'aide-mémoire HTTP Headers de l'OWASP, consulté le 2 novembre 2026, avec deux adaptations pour WordPress signalées comme telles : | En-tête | Valeur proposée | Rôle | |---|---|---| | Strict-Transport-Security | Pour commencer, max-age=300 (notre choix de départ) ; l'OWASP recommande à terme max-age=63072000; includeSubDomains; preload | Forcer HTTPS | | X-Content-Type-Options | nosniff (OWASP) | Bloquer la détection du type de fichier | | X-Frame-Options | SAMEORIGIN, ou frame-ancestors 'self' en CSP (adaptation WordPress) | Empêcher l'affichage dans un cadre externe | | Referrer-Policy | strict-origin-when-cross-origin (OWASP) | Limiter l'URL transmise aux autres sites | | Permissions-Policy | Désactiver les fonctions inutiles, par exemple geolocation=(), camera=(), microphone=() (OWASP) | Réduire les accès du navigateur | Pour X-Frame-Options, l'OWASP propose DENY, mais l'outil de personnalisation de WordPress affiche le site dans un cadre de même origine. WordPress envoie d'ailleurs lui-même SAMEORIGIN sur l'administration et la page de connexion, d'après le code de send_frame_options_header(). Pour HSTS, l'OWASP avertit qu'un réglage trop long ou un problème de certificat peut bloquer des visiteurs légitimes. Augmentez max-age par paliers ; includeSubDomains exige que tous les sous-domaines soient en HTTPS, et preload vient en dernier, car il est difficile à annuler. Une politique CSP stricte casse souvent l'éditeur de blocs : déployez-la d'abord avec l'en-tête Content-Security-Policy-Report-Only. Sur Nginx, la documentation du module headers précise qu'un bloc contenant ses propres add_header n'hérite plus de ceux du niveau supérieur. Notre tutoriel Nginx reverse proxy avec Docker Compose montre où placer ces directives dans une configuration HTTPS. --- 8. Sauvegardes 3-2-1 et tests de restauration La sauvegarde est la seule mesure qui répare au lieu de prévenir. Le guide Sauvegarde des systèmes d'information de l'ANSSI (version du 27 novembre 2025) recommande la règle 3-2-1 : 3 copies distinctes des données, c'est-à-dire la production et 2 sauvegardes sur des supports différents, dont 1 hors ligne. Notre adaptation pour un site WordPress : - Trois éléments ensemble : la base de données, wp-content et wp-config.php. - Une copie hors du serveur, chez un autre fournisseur que l'hébergeur. - Une copie hors ligne, au sens de l'ANSSI, qu'un attaquant présent sur le serveur ne peut pas effacer. cybermalveillance.gouv.fr insiste sur le test : sauvegardez le site, sa configuration et ses bases de données, puis testez la restauration. Nous conseillons un test par trimestre sur une copie de préproduction. Le choix de l'hébergeur compte aussi ; notre guide de l'hébergement cloud pour développeurs compare les offres. --- 9. Pare-feu applicatif, CDN et surveillance Un pare-feu applicatif (WAF) filtre les requêtes malveillantes avant qu'elles n'atteignent WordPress. La page officielle Brute Force Attacks cite Cloudflare, Sucuri ou le pare-feu de l'hébergeur. Selon la documentation de Cloudflare, un jeu de règles gérées gratuit est disponible sur toutes les offres, tandis que le jeu complet et celui de l'OWASP sont réservés aux offres payantes. Le pare-feu de Sucuri est un service payant activé en modifiant les DNS. Les hébergeurs proposent souvent un module comme ModSecurity, que le manuel officiel mentionne. Ne surestimez pas ces outils. Patchstack, qui vend sa propre protection, rapporte deux tests d'intrusion menés en 2025 chez des hébergeurs : les défenses classiques n'ont bloqué que 12 % des attaques visant des failles propres à WordPress, puis 26 % dans un test plus large. Côté surveillance, le manuel Hardening WordPress conseille de garder les journaux et de surveiller les modifications de fichiers, par exemple avec Git, inotify ou OSSEC. Un nouveau fichier .php dans wp-content/uploads doit déclencher une alerte. --- Quelle extension de sécurité choisir Une extension de sécurité WordPress regroupe plusieurs mesures de ce guide, sans remplacer les mises à jour ni les sauvegardes. Données relevées le 2 novembre 2026 sur les pages officielles de WordPress.org, classées par installations actives. Aucun lien n'est affilié. | Extension | Installations actives | Fonctions principales selon sa page officielle | |---|---|---| | Wordfence Security | Plus de 5 millions | Pare-feu en extension, analyse de logiciels malveillants, 2FA et clés d'accès ; règles du pare-feu avec 30 jours de retard en version gratuite | | All-In-One Security (AIOS) | Plus de 1 million | Limitation des connexions, 2FA, surveillance des fichiers, pare-feu, journal d'activité | | Limit Login Attempts Security | Plus de 1 million | Limitation des tentatives de connexion, protection de XML-RPC, 2FA | | Kadence Security | Plus de 700 000 | 2FA, protection contre la force brute, exigences de mot de passe ; intégration Patchstack en version Pro | | Sucuri Security | Plus de 600 000 | Journal d'activité, surveillance de l'intégrité des fichiers, analyse à distance, surveillance des listes noires, durcissement | | Two Factor | Plus de 100 000 | 2FA seule : application TOTP, e-mail, codes de secours | Selon le journal des modifications de l'extension (adresse better-wp-security), la version 10.0.0 renomme Solid Security, ex-iThemes Security, en Kadence Security. Le nombre d'installations mesure la popularité, pas la qualité. Notre conseil, sans classement : une seule extension de sécurité complète, pour éviter les conflits, ou une approche minimale qui combine Two Factor, une limitation des connexions en amont et un WAF. --- Site piraté : que faire Si votre site est défiguré ou redirige vers des pages inconnues, suivez la fiche réflexe « Défiguration de site Internet, que faire ? » de Cybermalveillance.gouv.fr (mise à jour le 28 octobre 2026). Ses étapes, résumées : 1. Isoler la machine touchée d'Internet, ou demander à l'hébergeur de le faire, sans l'éteindre : la fiche demande ensuite une copie de sa mémoire. 2. Conserver les preuves : journaux et captures d'écran. 3. Faire une copie complète de la machine et de sa mémoire, avant toute réparation. 4. Notifier la CNIL si des données personnelles sont touchées et que la violation présente un risque (voir plus bas). 5. Identifier le point d'entrée : selon la fiche, le plus souvent un mot de passe d'administration faible, un défaut de configuration ou une faille connue non corrigée. 6. Déposer plainte auprès de la police, de la gendarmerie ou par écrit au procureur. 7. Corriger les failles et changer tous les mots de passe avant la remise en ligne. 8. Contacter l'hébergeur, puis se faire assister au besoin par un professionnel. Pour le diagnostic et l'orientation, le service officiel 17Cyber, proposé par la police, la gendarmerie et Cybermalveillance.gouv.fr, guide les victimes. Côté WordPress, l'étape 7 inclut de régénérer les clés et salages pour déconnecter toutes les sessions et de révoquer les mots de passe d'application. Le RGPD ajoute une obligation. Selon l'article 33 du RGPD, le responsable du traitement notifie la violation à la CNIL dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf si elle n'est pas susceptible d'engendrer un risque pour les droits et libertés des personnes. Un prestataire sous-traitant prévient son client dans les meilleurs délais. Selon la page de notification de la CNIL, un risque élevé impose aussi d'informer les personnes concernées, et l'incident doit toujours être documenté en interne. Une défiguration qui entraîne une fuite, une altération ou une indisponibilité des données est une violation, rappelle la fiche de Cybermalveillance.gouv.fr. --- Ce que nous n'avons pas pu vérifier Plusieurs points restent incertains ou hors de portée de cette synthèse : - D'autres jeux de données que celui de Patchstack. Les rapports de Wordfence n'ont pas pu être lus au moment de la rédaction ; la page de Patchstack ne détaille pas sa méthode de comptage. - L'effet réel de chaque mesure. Aucun réglage n'a été testé sur un site en production. Les extraits sont recopiés de la documentation officielle et doivent être testés en préproduction. - La couverture du pare-feu gratuit de Cloudflare face aux failles propres à WordPress : la documentation consultée ne la détaille pas. --- Questions fréquentes Une extension de sécurité suffit-elle ? Non. Elle ne remplace ni les mises à jour, ni la suppression des extensions inutiles, ni des sauvegardes testées. La documentation officielle recommande aussi de bloquer les attaques en amont quand c'est possible. Faut-il désactiver l'API REST de WordPress ? Non. La FAQ officielle de l'API REST explique que la désactiver casse des fonctions de l'administration. Elle propose plutôt d'exiger une authentification avec le filtre rest_authentication_errors, à réserver aux sites qui n'exposent pas de contenu public par l'API. DISALLOW_FILE_MODS est-il recommandé ? Seulement si vos mises à jour passent par un déploiement. Selon le code de WP_Automatic_Updater::is_disabled(), cette constante désactive aussi les mises à jour automatiques de sécurité. Pour la plupart des sites, DISALLOW_FILE_EDIT suffit. Comment sécuriser WordPress sans compétences techniques ? Commencez par cinq mesures accessibles depuis l'administration : mises à jour automatiques, suppression des extensions inutiles, double authentification, gestionnaire de mots de passe et sauvegardes hors du serveur. Confiez ensuite wp-config.php, les permissions et les en-têtes à votre hébergeur ou à un prestataire. --- À propos de l'auteur Abdelilah Ourti est ingénieur IA et architecte logiciel. Il conçoit et déploie des applications web et des systèmes d'IA, et publie sur NeurauTech des guides et des comparatifs destinés aux développeurs francophones. Ses autres articles sont réunis sur sa page auteur. Méthode. Synthèse fondée exclusivement sur des sources publiques consultées les 1er et 2 novembre 2026 : manuels officiels de WordPress (Advanced Administration, REST API, référence du code, WP-CLI), pages des extensions sur WordPress.org, rapport de Patchstack, documentation de Nginx, de Cloudflare et de Sucuri, aide-mémoire de l'OWASP, guide de l'ANSSI, publications de Cybermalveillance.gouv.fr et de la CNIL. Les chiffres de Patchstack sont des données d'éditeur, signalées comme telles. Les citations issues de sources en anglais sont traduites par nos soins. Aucun test n'a été mené, aucun lien n'est affilié et aucune relation commerciale ne lie l'auteur aux éditeurs mentionnés. Une erreur ou un réglage qui a changé ? Écrivez à contact@neurautech.com : l'article sera corrigé et la date de mise à jour modifiée. Dernière mise à jour : 2 novembre 2026. Image : Brett Sayles via Pexels (Pexels License).

WordPress 7.1.4 security release: The updater flaw and what to do now Originally published at hamzaahmadaslam.com. How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing. The WordPress 7.1.4 security release fixes 22 vulnerabilities, including an updater flaw that needs no login and could allow remote code execution. Wordfence has recorded attack attempts against the flaw. Check your WordPress version, block public access to the upgrade folder, and review your server logs. What the WordPress 7.1.4 security release fixes WordPress released version 7.1.4 on October 28, 2026. The release addresses 22 security vulnerabilities across 17 advisories, according to WordPress's version documentation. The most concerning fix addresses a race condition in the core updater, reported by Umut Bayram. A race condition occurs when an outcome depends on which of two processes finishes first. Here, an attacker must reach temporary files while WordPress is updating. Successful exploitation could lead to remote code execution (RCE), meaning an attacker runs code on your server without needing a WordPress account. The remaining fixes cover several areas: - Contributor accounts can trigger stored cross-site scripting (XSS), unsafe Interactivity API bindings, prototype pollution, and browser denial of service. Many of these issues require a Contributor or higher account. Some also need another user to open malicious content. - Author accounts can trigger stored XSS in the Interactivity Router through uploaded text files. - Editor accounts can trigger stored XSS in the personal data erasure requests screen. - Other access problems include unpublished Customizer changes being exposed to visitors without accounts, a Notes API permissions flaw affecting certain custom roles, and multisite username handling. - Fixes without a stated role requirement include unsafe preg_replace() replacements in the Image and Playlist blocks, XSS in the Categories block, and post content shadowing Script Module data through a matching element ID. The Customizer changeset disclosure also requires no login. The updater flaw stands out because successful exploitation can execute code on the server. The release also updates bundled root certificates following the eMudhra revocation. How the WordPress upgrade race condition works During a full-package WordPress core update, the updater extracts downloaded files into a temporary directory under: wp-content/upgrade/ Before the fix, that staging directory had a predictable name. It was also commonly reachable through the public web server. The old cleanup process removed the directory's index.php guard, which normally prevents directory listings. For a few seconds, the server could expose a temporary copy of WordPress. That copy included wp-admin/setup-config.php, the installer that starts without the site's existing configuration. An attacker who requests the installer at the right moment can interact with the staged WordPress copy and progress to PHP code execution. According to Patchstack's analysis, the patch makes three relevant changes: 1. Adds 16 random characters to the temporary directory name. 2. Recreates and preserves the index.php guard. 3. Excludes wp-config.php from files copied out of the working directory. The window exists during full-package core updates, including unattended updates. The attacker must reach the vulnerable files before the updater removes them. Why an ordinary WordPress security plugin may miss it The malicious request targets a PHP file inside the staged copy. It does not load the site's normal WordPress installation. A security plugin that initializes through the site's usual WordPress loading process may never see that request. Wordfence's Extended Protection mode is an exception because its firewall can initialize before the requested PHP file. A web application firewall (WAF) filters incoming HTTP requests. A server-level rule denying public access to wp-content/upgrade/ removes this particular web entry point regardless of whether WordPress loads. This updater flaw is separate from the July 2026 wp2shell vulnerabilities, CVE-2026-60137 and CVE-2026-63030. How serious is CVE-2026-119977? The WordPress GitHub advisory rates the updater issue Low and lists no known CVE. Wordfence, acting as a CVE Numbering Authority (CNA), assigned CVE-2026-119977 and rated it 8.1, High, under CVSS 3.1. CVSS is a standardized vulnerability severity scoring system. The Wordfence assessment includes AC:H, meaning high attack complexity. Both assessments describe the same underlying flaw. Wordfence emphasizes the potential impact of successful remote code execution. Patchstack also assigns high attack complexity but says it would not describe exploitation as practical. That caution is based on the seconds-long window, the need for a full-package update, and the requirement that an attacker reach the staged installer in time. What Wordfence observed In its report, Wordfence states: - Its Premium, Care, and Response firewall rule went live on October 28 at 20:30 UTC. - The first matching request arrived nine minutes later. - During the first 21 hours, Wordfence recorded more than 18,500 requests targeting staged installer paths. - Two prominent sources repeatedly polled small groups of sites for roughly 14.5 hours. Wordfence says some requests tested alternate directory layouts rather than exact vulnerable paths. These figures measure requests and attempted exploitation. They do not establish successful code execution or the number of compromised sites. The cited primary reports do not confirm successful compromises. That leaves the outcome of the observed attempts unknown. Wordfence Free users are scheduled to receive the rule on November 27, 2026. Until then, free installations should not assume this particular rule is available. Even with the rule installed, verify your core version and block the upgrade directory at the server. Which WordPress versions contain the fix? The WordPress security advisory lists the following patched versions. Each fixes the updater race within its corresponding branch. | WordPress branch | Fixed release | |---|---| | 7.1 | 7.1.4 | | 7.0 | 7.0.8 | | 6.9 | 6.9.11 | | 6.8 | 6.8.12 | | 6.7 | 6.7.11 | | 6.6 | 6.6.11 | | 6.5 | 6.5.14 | | 6.4 | 6.4.14 | | 6.3 | 6.3.14 | | 6.2 | 6.2.15 | | 6.1 | 6.1.16 | | 6.0 | 6.0.18 | | 5.9 | 5.9.20 | | 5.8 | 5.8.19 | | 5.7 | 5.7.21 | | 5.6 | 5.6.23 | | 5.5 | 5.5.24 | | 5.4 | 5.4.25 | | 5.3 | 5.3.27 | | 5.2 | 5.2.30 | | 5.1 | 5.1.28 | | 5.0 | 5.0.31 | | 4.9 | 4.9.35 | | 4.8 | 4.8.34 | | 4.7 | 4.7.39 | WordPress explicitly states that version 4.6 and earlier no longer receive security updates. The older releases are courtesy backports. WordPress says only its newest version is actively supported, so treat an older patched branch as a temporary measure while planning an upgrade. Check one site Open your WordPress dashboard and go to Dashboard > Updates. Confirm that the installed version matches the fixed release for your branch. If it is older, arrange the security update. If you have SSH access and WP-CLI installed, run this from the WordPress installation directory: wp core version For a site in another directory: wp core version --path=/var/www/example.com Replace the example path with your installation's filesystem path. Check multiple sites For sites accessible through the same server account, use a list of their installation directories: for site in \ /var/www/site-one \ /var/www/site-two \ /var/www/site-three do printf '%s: ' "$site" wp core version --path="$site" done Replace those paths with your actual installations. For separate servers, run the command over SSH on each server, or use WP-CLI's --ssh global parameter with configured remote access. Each result must match the appropriate patched version in the table. Multisite installations share the same WordPress core files. Check the network's core version, then audit individual site administrators separately. Check automatic updates and disabled updates WordPress says eligible installations begin automatic background updates. That does not guarantee a particular site completed the process successfully. A failed download, filesystem permissions problem, hosting restriction, or intentionally disabled update can leave an older version installed. If core updates are disabled, arrange a manual or host-managed update after applying the server-level block. For managed hosting, ask the provider to confirm the installed build, successful completion, and the protection applied to temporary upgrade files. Request confirmation for every production environment, including staging sites reachable from the internet. Block access to wp-content/upgrade before updating If your site remains unpatched, establish the web-server restriction first. The update to the fixed release may itself begin under vulnerable updater code. Blocking the directory beforehand reduces exposure during that final update. Keep filesystem access available to WordPress. These rules block incoming web requests without preventing WordPress from writing temporary files. Nginx configuration Add the following location inside the relevant server block: location = /wp-content/upgrade { return 403; } location ^~ /wp-content/upgrade/ { return 403; } The ^~ prefix prevents a generic regex PHP location, such as location ~ \.php$, from taking precedence over requests within this directory. The exact-match location covers the directory path without a trailing slash. For a subdirectory WordPress installation, adjust the URL prefix accordingly. Use the Nginx location directive documentation when checking your existing configuration. After editing, test the configuration and reload the server: sudo nginx -t sudo systemctl reload nginx These commands assume Nginx runs under systemd. Check with your provider if your server uses a different process manager. Apache 2.4 and LiteSpeed using .htaccess For an Apache installation using mod_rewrite, place this rule near the beginning of the site's root .htaccess, before WordPress's standard rewrite rules: <IfModule mod_rewrite.c> RewriteEngine On RewriteRule ^wp-content/upgrade(?:/|$) - [F,END] </IfModule> Apache's [F] flag denies access with HTTP 403. [END] ends further per-directory rewrite processing. This example assumes WordPress sits at the site's URL root and that Apache permits rewrite rules through .htaccess. If mod_rewrite is unavailable, the rule inside IfModule will not apply. For hosts that use LiteSpeed, confirm that their .htaccess implementation supports the rule and test the public response. An alternative for Apache is a file named .htaccess inside wp-content/upgrade/: Require all denied This requires Apache 2.4 authorization support and permission to use the directive in .htaccess. The folder-local approach has a limitation: the old updater cleanup can delete files inside wp-content/upgrade/. Its restriction may disappear during the exact window you need to protect. Prefer the root .htaccess rule or a restriction in the server's virtual host configuration. The root rule survives cleanup of the upgrade directory. Refer to Apache's rewrite documentation when checking server permissions and rule behavior. Confirm the block returns 403 After applying the rule, request a nonexistent PHP path beneath the protected directory: curl -sS -o /dev/null -w '%{http_code}\n' \ https://example.com/wp-content/upgrade/security-check.php Example output (illustrative): 403 Replace the domain with your own. A 404 response does not prove the rule works because the requested file does not exist. A 301 or 302 may indicate a redirect before the block is reached. Test the final public hostname and any alternative route that reaches the origin server. If your CDN handles the request first, check that the origin also denies access. Never create a PHP test file in the upgrade directory. The nonexistent path is sufficient to test a path-based denial rule when correctly configured. Check access logs and WordPress for suspicious activity Start with the server's access logs, which record incoming HTTP requests. Review the period beginning before October 28 if your site was exposed or updated recently. Extend the review to include earlier full core updates if records are available. Search access logs On a server where the access log uses a conventional Nginx or Apache format, run: grep -Ei '/wp-content/upgrade/[^ "]*\.php' \ /var/log/nginx/access.log For Apache, substitute your actual access-log filename. To search for installer requests anywhere: grep -Ei '(/|%2f)setup-config\.php' \ /var/log/nginx/access.log Check archived and rotated logs too. Depending on your host, these may be separate files or compressed archives. Look closely at repeated requests, timestamp clusters around core updates, and paths containing wp-admin/setup-config.php below wp-content/upgrade/. A request is evidence of probing. An HTTP 200 response deserves investigation, but a status code alone does not prove code execution. The installer can also be requested during legitimate fresh installations. Compare suspicious entries with known maintenance activity. Check for changes inside WordPress List administrator users: wp user list --role=administrator \ --fields=ID,user_login,user_email,user_registered Review each administrator against your known team. For multisite, also check network super administrators in Network Admin. List installed plugins: wp plugin list Investigate unfamiliar plugins, particularly anything added around suspicious request times. Search for PHP files in the temporary upgrade area: find wp-content/upgrade -type f -name '*.php' Run this from your WordPress installation directory. Unexpected PHP files elsewhere in writable directories also deserve review. Do not delete unfamiliar files before establishing whether they belong to a legitimate deployment or plugin. Verify WordPress core checksums Run: wp core verify-checksums WP-CLI compares installed core files against the published checksums for the installed WordPress version. A successful result means the checked core files match their expected contents. It does not prove that the rest of the site is clean. A malicious plugin, altered theme, compromised user account, or additional file outside the checked core paths may remain undetected. Investigate checksum mismatches. If the site uses a localized WordPress package, supply the appropriate locale when required. Copy this checklist for each WordPress site Record one copy per installation. Agencies should track the site hostname, hosting provider, and person responsible alongside it. | Check | How to check | Expected result | Done | |---|---|---|---| | WordPress version | Dashboard > Updates or wp core version | Matches the fixed version for its branch | [ ] | | Server block | Inspect Nginx or Apache configuration | Public access to the upgrade directory is denied | [ ] | | HTTP 403 test | Use the curl command above | Returns 403 from the public hostname | [ ] | | Access logs | Search for PHP requests under wp-content/upgrade/ | No unexplained successful access or suspicious activity left uninvestigated | [ ] | | Administrator accounts | Dashboard > Users or wp user list | Every administrator is recognized and authorized | [ ] | | Plugin inventory | Review installed plugins using WP-CLI | Every installed plugin has a known purpose and owner | [ ] | | Core checksums | Run wp core verify-checksums | Core files verify, or every mismatch is explained | [ ] | Save the evidence with the site's maintenance record. Record the installed version, the date of the HTTP test, and any log entries that need further investigation. A clean checklist today does not establish whether an earlier compromise occurred. Limited log retention, deleted evidence, and changes outside core files can prevent detection. What to do if your site is still vulnerable If you find an unpatched version, apply the server restriction and verify that it returns 403. Then install the fixed release and confirm the installed version. For WordPress 4.6 and earlier, arrange a migration to a maintained version. There is no corresponding security backport for those branches. Keep the server restriction after updating. It limits unnecessary public access to temporary installation files during future updates. For broader site protection beyond this issue, use the WordPress security hardening checklist. If your review reveals an unknown administrator, unexplained PHP files, modified core files, or other convincing signs of compromise, preserve the relevant logs and begin a cleanup. The guide to cleaning a hacked WordPress site covers that process. If you need help investigating or restoring a compromised installation, the WordPress malware removal service offers a free assessment followed by a fixed-price single-site cleanup.

WordPressからnpm・AIツールまで。直近1年の脆弱性と侵害12事例 修正版を入れたあと、何をすれば対応を終えたと言えるのだろう。 この問いは製品が変わると答えも変わる。SiteGuard Server Editionでは更新する前に攻撃の痕跡を保全するよう案内された。Metabaseでは更新に加えて、利用者のセッションや接続先データベースの認証情報まで確認するよう求められた。Trivyでは安全性を調べるために動かしたツール自体が侵害され、実行した環境の秘密情報を点検する事態になった。Axiosではアプリから使う前にも、依存の導入時に不正なコードが動く仕組みが仕込まれた。 どれも「更新が大事」という一文には収まる。でも、その一文だけでは作業の順番も、確認する範囲も分からない。 前回のPHP2Shellの記事では、WordPressの緊急点検を通じて、設定の意味や残すべき機能を見直した。今回はそこから範囲を広げ、2025年11月1日から2026年10月31日までに公表・悪用・対応が報告された脆弱性と供給網侵害を調べた。WordPressやWebサービスの開発・運用に近い12の事例群を、実際の対応と一緒に追っていく。 公表された悪用・対応の記録をもとに、どの構成が対象になり、更新後にどんな作業が残るのかをたどる。 解説図：サイトの運用では公開ページ以外にも、自動化、接続先、開発環境、作業する人の端末が関係する。 自分に関係する事例から読む 読みたい場所へ進めるよう、まず今回の12事例を並べた。CVEは脆弱性を識別する番号で、一つの製品に複数付くこともある。関連する問題をまとめ、AxiosやLiteLLMのような配布物の侵害も扱うため、12事例とCVEの数は一致しない。 使っているもの・担当する範囲 事例 特に確かめたいこと WordPress wp2shell 同じ系列で更新が実際に完了しているか Reactを使うサーバー React2Shell Server Componentsを処理しているか 自動化ワークフロー n8n 編集権限と公開フォームを別々に確認したか AIフローの公開 Langflow フローの実行と変更を区別できているか BI・分析基盤 Metabase 保存された認証情報まで調査したか 自分で管理するDB MongoBleed 認証より前の処理も修正されているか サーバー用WAF SiteGuard Server Edition 更新前に診断情報を保全したか 機器へのクラウドSSO FortiCloud SSO 追加告知と設定流出への対処を追ったか CI/CDの脆弱性検査 Trivy 実行した配布物と露出した秘密を確認したか PythonのAIゲートウェイ LiteLLM 3月と10月で異なる配布物と経路を確認したか npmの依存とビルド環境 Axios 導入時の実行と、端末・CIの秘密情報まで調べたか 普段使うブラウザー Chrome 更新の取得と適用を両方確認したか ! 情報の基準日は2026年10月31日。本文中の修正版は原則として「その問題への修正が最初に入ったバージョン」を示す。現在導入するバージョンは、後続の修正とサポート状況を含めて公式の現行情報で選んでほしい。図は説明用で、攻撃ログや被害画面を再現したものではない。 時系列も一度見ておきたい。告知が出た日、攻撃を観測した日、悪用を確認した一覧へ追加された日は、それぞれ意味が違う。後から出た調査報告を、攻撃の始まった日と読み替えると、対応に使える時間を見誤ってしまう。 解説図：選んだ事例の主な公表時期。すべての脆弱性を網羅した年表でも、被害件数の比較でもない。 WordPressのwp2shell PHP2Shellと名前が似ているが、こちらはWordPress本体の別の問題だ。2026年7月17日、WordPressは7.0.2のセキュリティリリースで二つの脆弱性を修正した。SQLインジェクションのCVE-2026-60137と、REST APIのバッチ処理におけるルートの取り違えに関するCVE-2026-63030だ。WordPressのリリース告知 二つがつながったときの影響 WordPress 6.9以降では、この二つを組み合わせると遠隔でのコード実行（RCE）につながり得る。管理画面に入るためのパスワードが先に盗まれていなくても問題になる、という点が重い。IPAは7月22日の注意喚起で、標準構成で管理者権限などを要さず成立する可能性と、CISAの悪用確認済み脆弱性カタログへの登録を伝えている。IPAの注意喚起 ここで、WordPressのバージョンをまとめて扱うと話がずれる。6.8系列ではSQLインジェクションの問題が対象になり、6.9系列以降で二つを組み合わせた影響が問題になる。同じ「WordPressに脆弱性」という見出しでも、中身は一段違う。 開発元のアドバイザリもSQLインジェクションと組み合わせによるコード実行を分けている。一つ目の深刻度だけを見て軽く扱ったり、逆にすべての旧バージョンが同じ条件でコード実行まで到達すると決めたりせず、系列と組み合わせを読む必要がある。SQLインジェクションの開発元情報、バッチ処理の開発元情報 解説図：単独の問題と攻撃チェーンの影響範囲を分ける。古い系列すべてを同じ条件として扱わない。 自動更新の案内と更新完了 この事例で注目したい対応は、WordPress.orgが影響するバージョンへ強制自動更新を有効化したことだ。利用者全員がニュースに気づき、手動で更新してくれることだけに頼らない対応だった。 ただし、提供側が更新を配信したことと、自分のサイトで更新が終わったことは別に確かめる。IPAも、設定や構成、更新失敗によって適用されない場合があるため、管理画面などで実際のバージョンを確認するよう案内している。管理を委託しているなら、「自動更新の対象です」という回答の先に、稼働しているバージョンと確認時点まで聞きたい。 当時の系列 この問題への修正境界 6.8 6.8.6。SQLインジェクションへの修正 6.9 6.9.5。二つの問題への修正 7.0 7.0.2。二つの問題への修正 この表のバージョンを、10月末に新しく導入するバージョンの指定にはしない。同じ系列にも後続リリースがある。公式のWordPressのバージョン一覧と現在の告知を合わせて確認する。 解説図：更新を配信する側の対応と、利用するサイトでの適用確認をつなぐ。 運用へ持ち帰るなら、WordPress本体のバージョンを記録し、使っている系列の修正状況を確認する。そのうえでログイン、記事の表示、フォーム、管理画面の更新など、通常の操作を通す。REST APIの名前を見て一括で閉じる前に、そのAPIを使う公開機能や編集機能が何かを確かめたい。入口を塞ぐ判断にも、止まる機能との対応が要る。 React2Shell 2025年12月3日に公表されたCVE-2025-55182は、React Server Components（RSC）の処理に関係する認証前のコード実行の脆弱性だ。名前を見て「Reactを使っているから全部同じ」と受け取ると、必要な点検を外してしまう。React公式の告知 ブラウザーとサーバーを分ける 今回問題になったのは、Server Componentsを処理するサーバー側のパッケージだ。ブラウザー内だけで動くReactアプリまで一律に対象になるわけではない。一方、自分でServer Functionを書いていなくても、サーバー側でRSCを扱う構成なら確認が必要になる。 「画面を作るライブラリ」と思っていたものが、サーバーへ届く入力を処理している。その構成を把握していないと、フロントエンド担当とサーバー担当の間で更新の担当が浮いてしまう。アプリの名前より、どこでどのパッケージが動くのかをたどる方が役に立つ。 当初はreact-server-dom-webpack、react-server-dom-parcel、react-server-dom-turbopackの19.0、19.1.0、19.1.1、19.2.0が影響し、このRCEへの修正は19.0.1、19.1.2、19.2.1に入った。ただし、その後のDoSや情報露出などの追加問題とは区別する。最初の修正版の数字だけを、今の推奨バージョンとしてコピーしない。 解説図：確認するのは、名前にReactがあるかだけでなく、サーバーで何を処理しているか。 公開から適用までの時間 AWSは12月4日の報告で、公表から数時間以内に攻撃試行を観測したと説明した。Google Threat Intelligence Groupは12月12日、侵害調査で確認したバックドアや暗号資産マイナーの配備などを報告している。攻撃試行の観測と、侵害後の調査結果は分けて読む。AWSの観測報告、Googleの調査報告 この短さを見ると、週末にまとめてニュースを読む運用だけでは間に合わない場合がある。とはいえ、焦って別のアプリを更新しても解決しない。まず影響する構成と外部からの到達可否を押さえ、更新が必要なアプリとデプロイ先を担当者に伝える。速さと対象の特定は両方必要になる。 Vercelの振り返りにはWAFへの対応だけでなく、影響するデプロイへの通知、更新を支援するCLI、修正PRの作成といった手段が出てくる。修正コードを公開したあと、利用者が自分の環境へ届けるまでに作業があることがよく分かる。Vercelの対応記録 解説図：依存ファイルを直した状態と、その修正を含むアプリが公開環境で動く状態を区別する。 自分の運用ではpackage.jsonの記載だけで判断せず、解決された依存のバージョンとデプロイ済みの成果物を確認する場面になる。更新のPRがマージされても、以前のコンテナーが動いたままなら、公開環境への適用確認は残っている。WAFで一部の通信を遮断できることも、脆弱な処理自体が修正された証拠にはならない。 n8nの編集権限と公開フォーム n8nのような自動化ツールには、APIキーや接続情報を預け、複数のサービスをまとめて動かすことがある。ワークフローを作れる人は、見た目以上に強い権限を持つ。その一方で、公開フォームはログインしていない人にも使わせたい。この二つを分けて考えさせられるのが、年末から翌年に続いた一連の問題だ。 三つの問題を条件と修正版で分ける CVE 開発元の公表日 主な条件と当該問題の修正境界 CVE-2025-68613 2025-12-19 認証済み利用者の式評価に関係。1.120.4、1.121.1で修正 CVE-2026-21858 2026-01-07 一部のフォーム系ワークフローを通じた未認証のファイルアクセス。1.121.0で修正 CVE-2026-25049 2026-02-04 編集権限を持つ認証済み利用者による式評価の追加の回避。1.123.17、2.5.2で修正 出典は開発元の告知と、開発元が登録したCVEの公開レコードだ。68613の修正バージョンはCVEレコードでも確認できる。CVE-2025-68613の告知、CVE-2026-21858、CVE-2026-25049 この三つを「n8nで未認証RCE」と一行にまとめると、個々の条件が消えてしまう。式を設定する利用者の権限が関係する問題と、公開されたフォームから届く問題では、確認する処理が違う。一つの問題の修正版が後から公表されたすべての問題まで直しているわけでもない。 解説図：ワークフローを編集する人と、フォームを使う人では、必要な権限と到達する処理が違う。 組み合わせた悪用も報告された VulnCheckは2026年3月27日、CVE-2026-21858とCVE-2025-68613を組み合わせた、未認証でのコード実行につながる攻撃試行を観測したと報告した。カナダ政府の告知でも、CVE-2025-68613のCISAカタログへの追加が伝えられている。VulnCheckの観測、カナダ政府の注意喚起 「認証済みの人しか使えない問題だから、外部の人には関係しない」と区切っていたところへ、別の入口がつながる。WordPressの事例と同様、脆弱性は一つずつの説明だけでなく、同じ環境で組み合わさる条件も見る必要がある。 更新までの対処としては、開発元が示す公開フォームやWebhookへの制限、編集できる利用者の制限、OS権限やネットワークの到達先の制限を検討する。ただし、これらは適用条件を確認して使う暫定的な対処であり、修正の適用と同じ状態にはならない。 解説図：ツールを更新する作業と、預けている権限・接続情報を確認する作業を合わせて考える。 自動化は便利になるほど、連携先が増えていく。だから、n8n自身の管理者パスワードだけを点検して終わらせたくない。影響を受けた可能性のあるワークフローが、どの認証情報を利用でき、どのサーバーへ接続できたかをたどる。秘密情報が露出したと判断した場合は、接続先側での失効や再発行も対応に含める。これは、このツールを使うときの権限設計にもそのまま返ってくる話だ。 Langflowの公開フロー AIのフローを公開するとき、外から使わせたいのは、用意した処理の実行だ。その処理の中身まで外部の人が差し替えてよいわけではない。LangflowのCVE-2026-33017は、この区別が崩れる問題だった。 実行する権限と変更する権限 開発元のアドバイザリでは公開フローを構築・実行する経路で、保存済みの定義だけでなく外部入力のフローデータを受け付け、サーバー側でPythonの処理へ渡してしまう問題が説明されている。影響欄は1.8.2以下、当該問題への修正境界は1.9.0だ。公開機能の使い方や認証設定などを含めて条件を確認する。Langflowの開発元情報 たとえば「このフォームから質問してよい」と「フォームの裏で動くプログラムを渡してよい」は、同じ許可ではない。公開した処理を利用させる機能に、処理の定義そのものを受け取る機能が混ざれば、許可した操作の範囲が変わってしまう。 点検したいのは、ログイン画面があるかだけではない。公開しているフロー、その識別子が使われる経路、外部から受け取るデータ、認証を通る場所を対応させる。管理画面が閉じていても、公開実行用のAPIは別に動いていることがある。 解説図：用意した処理を呼び出す許可と、サーバーで動く処理を差し替える許可を分けて考える。 約20時間という観測 Sysdigは3月19日の報告で、脆弱なLangflowを置いた観測環境に、アドバイザリ公開から約20時間後には攻撃試行が届いたと説明した。3月17日20:05 UTCのアドバイザリ公開に対し、最初の観測は3月18日16:04 UTCごろだ。Sysdigの観測報告、公開日時を示すAdvisory API ここで「約20時間」の起点はCVEレコードの公開ではない。CVEレコードは3月20日で、アドバイザリや観測報告と日が違う。また、この報告が示すのはハニーポットで観測した攻撃試行であり、実在する利用企業が何社侵害されたかという件数ではない。 この短い間隔を、単に「攻撃が速くて怖い」で終わらせたくない。公開フローが外から使えること、そこに秘密情報が置かれること、利用者自身がインスタンスに更新を適用することが重なっている。ニュースの購読先と、影響を受けるインスタンスを見つける手段がつながっているかを考える材料になる。 解説図：約20時間はアドバイザリ公開からの間隔。報告日と出来事の日を分けると、経緯を取り違えにくい。 当面の露出を減らすための公開経路の制限や前段での認証と、ソフトウェアを修正する作業は分けて扱う。Sysdigは保持していたシークレットの点検・交換や、不審な外向き通信の確認も挙げている。Langflowを修正版に更新しただけで、既に利用できた接続情報まで無効になったとは判断できない。 なお、LangflowにはCVE-2025-3248という別の認証不足の問題もある。初回公表は今回の期間より前だが、2026年7月にも悪用の観測が報告された。新しい問題の修正に追われるなかで、以前から動く別インスタンスが残っていないかも見たい。新しいニュースだけを読むことと、手元の古い環境を把握することは、別の作業になる。以前の問題の開発元情報、7月の観測報告 Metabaseと接続先データベース BIツールを一台更新する話だと思って読むと、対応範囲の広さに目が止まる。MetabaseのCVE-2026-72898では、BIツール自身への侵入から、そのツールが接続しているデータベースへ影響が広がり得る。 二つのデータベースを分ける Metabaseは2026年8月6日、認証なしで届くAPIのSQLインジェクションを公表した。攻撃者がMetabaseのアプリケーションデータベースに不正なSQLを実行し、Metabaseの管理者権限を得る可能性がある問題だ。ここでいうアプリケーションデータベースは、Metabase自身の利用者や設定などを持つ側を指す。開発元アドバイザリ その管理権限を取られると、アプリに保存された接続情報や設定へ手が届く可能性がある。そこから、分析用に接続している別のデータベースの情報が問題になる。「BIの画面を見られた」で止めず、アプリ自身のDBと、アプリが接続する先のDBを分けてたどりたい。 開発元はMetabase Cloudが未知の脆弱性を使った攻撃を受け、対象エンドポイントを遮断したうえで修正したと説明した。公表時点でCloud利用者の環境は修正済みと案内し、自己管理している利用者には更新と追加の点検を求めている。Metabaseの対応告知 解説図：アプリの設定を持つDBと、業務データを読む接続先DBを分ける。侵害調査では両方が関係する。 更新後に残った作業 OSS版の当時の修正境界は、0.58.24、0.59.21、0.60.17、0.61.11、0.62.9、0.63.5だった。利用するバージョンの種類と系列を、開発元の対応表に照らして確認する。そのうえで、対象の/api/session/reset_passwordが公開されていた場合、開発元は次の点検も案内した。JPCERT/CCの注意喚起 有効な利用者セッションを失効させる。 APIキーと管理者アカウントに見覚えのない変更がないか調べる。 接続先データベースの認証情報を交換する。 Metabaseと接続先DBのログや操作履歴を調べる。 「更新後にパスワードを変えましょう」という一般論より、対象がずっと具体的だ。アプリを更新する担当と、データベースの認証情報を管理する担当が別なら、後半の仕事を誰が持つかも決める必要がある。クラウドの修正完了の案内を読んだだけでは、接続先側の確認まで終えたことにはならない。 解説図：公開APIの修正と、利用できた権限や認証情報への対処を別の項目として進める。 ログの読み方も具体的だった。開発元が示したパターンには、パスワード再設定のAPIへのPOSTがHTTP 400となり、続く利用者情報の取得がHTTP 200になる組み合わせがある。一つ目がエラーだからといって、そこで攻撃も失敗したとは決められない。エンドポイント、順番、その後の操作を合わせて調べるための手がかりだ。 もちろん、その通信を一度見つけたことだけで、影響の全範囲まで判明するわけではない。管理者の追加、接続設定の変更、DBの読み出しなど、次の調査へつなげる。JPCERT/CCもインターネットから届く状態だった環境では、更新だけで完了せず侵害有無を確認するよう促している。 MongoBleedと認証前の処理 DBには強いパスワードを付け、利用者ごとの権限も絞る。その対策は必要だが、通信が認証にたどり着く前の処理にも不備は起こる。MongoDB ServerのCVE-2025-14847、通称MongoBleedはその点を確かめる事例になる。 認証より手前で読むデータ 問題はzlib圧縮を扱う通信処理にあり、認証前のクライアントから、未初期化のヒープメモリーを読み出される可能性があった。MongoDBに到達できることが関係し、認証を有効にしただけでこの処理が修正されるわけではない。一方、この問題をそのまま「任意のコードを実行できる」「DBの全件を確実に持ち出せる」と書き換えるのも違う。MongoDBのセキュリティ情報、公式の修正チケット ここで確認するのは、DBのネットワーク処理と認証の順番だ。DBへ接続できる送信元を絞ること、通信処理の修正を適用すること、利用者の認証を設けることは、それぞれ担当する場所が違う。どれか一つを済ませたことで、ほかの対処まで不要になったとは考えない。 解説図：認証があることと、認証前の通信処理が修正されていることを区別する。 Atlasと自己管理版の対応 MongoDBの振り返りでは、社内で問題を発見したのは12月12日。Atlas全体には12月18日までに修正を適用し、12月19日にCVEを公表したと説明されている。管理サービスでは提供側が先に修正を進められるが、自己管理のサーバーでは利用者が更新する範囲が残る。MongoDBの対応時系列 当該問題への修正境界には8.2.3、8.0.17、7.0.28、6.0.27、5.0.32、4.4.30が挙げられた。更新がすぐできない場合の暫定策としては、サーバーの圧縮設定からzlibを明示的に外す方法も案内された。利用中の構成と公式手順を確かめ、設定変更をソフトウェアの修正と取り違えないようにする。 ここで「マネージドだから確認しなくてよい」とまでは言えない。提供元の修正対象に、自分が使っているサービスや構成が含まれているかは見る必要がある。逆にAtlasについての修正完了の説明を、自分で立てたMongoDBサーバーにも適用済みだと読んではいけない。製品名が同じでも、更新を実施する担当は変わる。 解説図：管理を誰に任せているかで確認先が変わる。悪用確認済み一覧への追加日は攻撃開始日を示さない。 当初のMongoDBの説明には、悪用や顧客データ侵害の証拠はないという記述があった。その後、CISAは12月29日に悪用確認済みカタログへ追加した。この二つを並べたとき、初期の説明を現在も続く「悪用はない」という断定として読むと誤る。情報が更新された順番を残すことが大切だ。当時のMongoDBの案内、CISAの公式カタログデータ 運用へ置き換えると、DBを置いている場所、管理サービスか自己管理か、公開範囲、圧縮設定、適用されたバージョンを確認する作業になる。「DBには認証がある」という回答の先を、通信が届く位置から見直せる事例だ。 SiteGuard Server Editionと痕跡の保全 守るために置いたWAFも、更新や侵害調査の対象になる。これはWAFが役に立たないという話ではない。防御製品にもソフトウェアと権限があり、その製品が何を処理するかまで管理する話だ。 統計機能の脆弱性 EGセキュアソリューションズは2026年10月14日、SiteGuard Server Editionの統計機能にあるCVE-2026-106931を公表した。OSコマンドインジェクションの問題で、製品が動くサーバー上でrootまたはSYSTEM権限のコマンド実行につながり得る。同社は悪用を確認しているとも説明した。開発元の告知 対象バージョンはVer2.20以降で、統計機能が有効な構成が影響する。同機能は初期値でも有効とされている。製品名、バージョン、機能を合わせて照合する必要がある。WordPress用のSiteGuard WP Pluginなど、名前にSiteGuardが付くすべての製品へ、この影響を広げてはいけない。 また、公式に示された評価にはローカルの攻撃経路と低い権限の前提がある。この説明を、WAFの公開URLへ誰でも一回アクセスすれば侵入できる話に置き換えない。影響が大きいことと、成立条件を省いてよいことは別だ。JVNの情報 解説図：製品名だけで判断せず、バージョンと機能を照合する。別製品や異なる攻撃条件へ一般化しない。 更新より先に残すもの この事例で特に覚えておきたいのは、更新やパッチの適用前に「診断情報」を取得して保管するという案内だ。更新によって攻撃の痕跡が消える可能性があるため、調査に使う情報を先に残す必要があった。JPCERT/CCもこの順序を注意事項として取り上げている。JPCERT/CCの注意喚起 「一刻も早く更新する」と「調査の材料を残す」は、どちらかを無視すればよい関係ではない。この製品では公式に案内された診断情報の取得を先に行い、そのあとに更新・パッチへ進むという、具体的な順番が示されている。 当該修正はApache版・Nginx版・IIS版では8.00 Update5、FreeBSDのApache版・Nginx版では7.00 Update6に入った。IIS版の3.10から4.00 Update4は影響対象から除かれる。更新が難しい利用者向けには対象ファイルを差し替えるパッチ、回避策としては統計機能の無効化も案内された。バージョンの文字列をざっと読まず、OSと製品版を組み合わせて選ぶ部分だ。 解説図：この製品では更新によって失われ得る診断情報を先に残すよう公式に案内された。 開発元はサポート契約がある利用者には9月29日に個別通知したとも説明している。一般向けの公表日と、契約先へ通知した日は同じではない。運用側ではニュースだけでなく、契約先に届く保守通知が誰へ届き、誰が判断するのかも点検したい。 レンタルサーバーに付属するWAFを使っている場合も、「自分が製品を直接契約していないから関係がない」とは判断せず、提供元の告知で対象と対応状況を確認する。利用者が変更できる設定と、提供側が更新する製品本体を分けて聞くと、問い合わせも具体的になる。 FortiCloud SSOの連続した告知 「先月、言われたバージョンへ更新した」。その記録は大事だが、翌月に別の入口の問題が公表されれば、もう一度確認することになる。FortiCloud SSOの事例は、更新履歴を残すことと、追加告知を追うことの両方を考えさせる。 12月と翌1月の問題 2025年12月9日に公表されたCVE-2025-59718とCVE-2025-59719は、FortiCloud SSOが有効な対象装置への認証回避に関係する。続く2026年1月、Fortinetは当時の最新リリースに更新済みの装置にも類似の不正ログインがあったと報告し、別の攻撃経路を調査した。Fortinetの調査と更新履歴 1月27日に公表されたのがCVE-2026-24858だ。Fortinetが登録したCVEの公開レコードには、攻撃者自身がFortiCloudアカウントと登録済みデバイスを持つ条件が記載されている。標的の装置へ正規にログインできる資格が先に必要、という意味ではない。ただし、12月の問題と同じ「未認証の攻撃者」という一文で、条件をまとめて落とすのも正確ではない。Fortinetが登録したCVEレコード また、対象は訂正後のFortiCloud SSOの範囲で読む。Fortinetは1月28日、第三者のSAML IdPとFortiAuthenticatorはこの問題の対象ではないと明示した。「SSOを使っているから全部同じ」でも、「SSOなら認証があるから心配ない」でも判断できない。 解説図：前の修正の有無と、あとから判明した別の経路を分ける。告知の訂正まで時系列に残す。 提供側の停止と利用側の点検 Fortinetの更新履歴では1月23日に悪用されたアカウントを無効化し、1月26日にFortiCloud SSOを停止した。1月27日には脆弱な装置からのアクセスをサポートしない条件でSSOを再開したと説明されている。これは提供側が実際に行った対応だ。 一方、利用者側には対象装置のファームウェア更新、想定外の管理者アカウントや設定変更の点検が求められる。侵害の兆候がある場合は、装置と設定を侵害済みとして扱い、正常な設定への復旧や変更の監査、認証情報の交換へ進むよう勧められている。提供側でSSOが再開したことだけで、個々の装置の設定まで元に戻ったわけではない。Fortinet公式の復旧案内を含む調査報告 認証情報の交換には装置の管理者パスワード以外も関係する。LDAPやADとの連携、VPNなど、設定に含まれる秘密情報を確認する。外部へ持ち出された可能性のある設定が、別のシステムへ入る材料を含んでいないか、という見方だ。 解説図：サービス提供側の対応後も、利用側では装置の設定とそれに含まれる認証情報を確認する。 FortiOSの7.4系列を例にすると、12月のCVE-2025-59718への修正指定は7.4.9以上、1月のCVE-2026-24858への修正指定は7.4.11以上になる。これはそれぞれの問題に対する修正境界で、今から選ぶ全製品共通の最新バージョン一覧ではない。12月のCVEレコード、1月のCVEレコード このような対応では「更新済み」という一語だけを記録すると、どの問題まで対応したかが後で分からなくなる。対象CVE、製品と系列、適用したバージョン、追加告知の確認時点を一緒に残すと、次の知らせが来たときに確認しやすい。 Trivyと検査ツールの配布経路 脆弱性を調べるためにCIで動かしたスキャナーが秘密情報を持ち出す側になっていた。安全を確かめるための道具まで、どこから届き、何の権限で動くかをたどる必要がある。 バージョン番号だけでは対象が決まらない Trivyでは2026年3月19日、悪意あるコードを含むv0.69.4が配布された。Actionの既存タグも書き換えられ、その後にはDocker Hubの配布物への影響も公表された。CVE-2026-33634が割り当てられているが、通常の機能の不備にパッチを当てるだけで整理できる事例ではない。Trivy公式アドバイザリ 利用側が確認するのは、Trivyの数字だけではない。本体をどこから取得したか、どのActionを参照したか、タグかコミットSHAか、いつ実行したか。さらに、その処理にどんな秘密情報が渡されていたかを調べる。 同じタグを使っていても、取得した時点で中身が違うことがある。また、参照しているActionをSHAで固定していても、そのActionが内部で別の可変タグを呼ぶ構成なら、そこで参照先が変わり得る。固定した一行だけを見て安心せず、実際に呼ばれる配布物をたどる必要がある。 解説図：信用して実行する道具も取得元・参照先・実行時刻と渡している権限を確認する対象になる。 トークンを変える順番 3月30日の当事者の振り返りでは既存のGitHub・レジストリーのトークンを失効させてから、新しいアクセスを発行する対応が説明されている。初期の認証情報の更新が複雑で、別アカウントを通じたアクセスが残った経緯も報告された。危険なワークフローの実行条件の除去、SHA固定、リリースの不変化なども対策に含まれている。Trivyの事後報告、Aquaの調査・対応の更新 ここは利用側でも順序を考えたい。侵害された可能性のあるジョブが動いたまま、新しいキーだけを渡せば、それも読める状態にしてしまう。危険な実行を止め、影響する成果物と実行履歴を調べ、露出した秘密を失効・再発行し、安全な状態を確認した環境で再開する。この順序は今回の事例から運用へ引きつけた考察だ。 利用者側の判断も公表されている。Apache Software Foundationは3月20日の初報で、調査の間、それまで利用を許可していた関連Actionを無効化し、ビルドが失敗する可能性も明示した。調査中の段階で利用を止める範囲と、その業務への影響を伝えた例として読める。これは同組織の秘密情報流出がすべて確認された、という意味ではない。Apacheの初報 解説図：悪意ある配布物を除くだけでは、実行中に利用できた秘密情報までは失効しない。 当時の退避先として示された本体v0.69.2やv0.69.3と、情報基準日時点の公式最新リリースv0.76.1も区別する。古い対応記事から安全な退避先を見つけても、そのバージョンを使い続ける指示と読み替えない。Trivyのリリース一覧 検査ツールを入れたこと自体が、検査の完了を保証するわけではない。どこから入手し、何の権限で動かし、その結果を誰が読むのかまでが、CIで検査を運用する仕事になる。 LiteLLMで二度起きた配布物の侵害 Trivyの影響はそのツールを直接動かした組織だけにとどまらなかった。複数のLLMへの接続をまとめるLiteLLMは、3月のPyPI侵害とTrivyの関係を10月30日の振り返りで説明している。さらに10月には、別の経路から正規のリリース工程を使われた。同じ製品の事件でも、前回の「対象外」という説明を使い回せない。 3月と10月では、影響する配布物が違う 出来事 公式に示された主な対象と境界 2026-03-24 PyPIのlitellm==1.82.7、1.82.8。当時の公式Proxy Dockerイメージは非対象 2026-10-21 PyPIのlitellm==1.107.0と、公式が列挙したDocker Hub・GHCRのコンテナ。非公開のEnterprise配布は非対象 3月の公式初報はCIのセキュリティ検査に使ったTrivyの依存を侵害の起点とみていた。悪性版には認証情報を集めて外部へ送るコードが含まれた。公式Proxy Dockerが影響しなかったのは、その配布経路が当該PyPIパッケージに依存していなかったためだ。「LiteLLM全体が同じ状態」だったのではない。3月の公式報告 10月はコンテナも対象になった。v1.107.0だけでなく、latest、main-latest、main-stableも悪性イメージを指した時間帯がある。今のタグが正常な参照先へ戻っていても、以前に取得したイメージまで変わらない。取得・実行時刻とイメージの内容を識別するdigestを、10月の公式な対象一覧へ照らす必要がある。 解説図：3月の「公式Dockerは非対象」を、別事件である10月へ広げない。タグ名だけでなく、取得した内容を確かめる。 正規の工程を通っていても、入力と権限を調べる 10月23日の原因分析では、5月に公開リポジトリーへ誤って入った内部サービスの管理キーが、削除後も失効されずに残ったと説明された。攻撃者はそのキーからGitHub組織の所有者のトークンを取得し、リリース工程が読むソースを別のリポジトリーへ変更した。さらに別の盗難トークンで承認し、正規の工程から悪性版をビルド・配布させた。10月の公式の原因分析 ファイルから秘密を消すことと、その秘密を無効にすることは違う。10月30日の説明でも、悪性版に有効な署名とTrusted Publishingの来歴があったと報告された。署名や公開元の確認に加え、リリースに使うソースと承認権限まで調べる理由が見える。再発防止の説明 影響する環境で、確認のためのpipを動かさない 10月の公式案内は、影響環境でPythonを起動するとcook.pthやsitecustomize.pyが再実行され、pipも例外ではないと警告した。慌ててpip installから始めない。まず疑わしい実行を止めて記録を保全し、正常な別環境から対象の配布物と実行履歴を調べる。痕跡のファイルが見つからないことも、未侵害の証明にはならない。利用者向けの復旧案内 侵害が疑われる環境では、LLM提供元のAPIキーだけでなく、DBのパスワード、クラウドの実行権限、そのホストから利用できた秘密情報まで確認する。正常な別端末から失効・交換し、既知の正常な状態から実行環境を再構築する。古い配布物を削除する作業だけでは、既に利用できた認証情報を無効にできない。 解説図：確認コマンド自体が不正コードを再実行する場合がある。対象の特定、秘密情報の処置、環境の復旧を順序立てて進める。 Axiosとnpmの配布経路 アプリからHTTPリクエストを送る前に、ライブラリの導入だけで端末の侵害につながり得る。Axiosのサプライチェーン攻撃で押さえたいのは、攻撃が始まる場所だ。公開したWebアプリだけを点検しても、開発端末やCIで起きたことを見落としてしまう。 2026年3月31日、乗っ取られたメンテナーのnpmアカウントから、悪意ある依存を含むAxiosが公開された。Aikidoが整理した対象はaxios@1.14.1とaxios@0.30.4。普段使っているパッケージの正規の名前で配られ、二つの系列が影響を受けた。Aikidoの調査記事 importしていない依存が、導入時に動く 追加されたのはplain-crypto-js@4.2.1という依存パッケージだった。解析では、Axios本体のソースからこのパッケージをimportするコードは見つからなかった。攻撃者が使ったのは、インストール時に実行されるpostinstallスクリプトだ。そこから、端末を遠隔操作するための不正プログラムであるRATを、macOS、Windows、Linuxへ配備する仕組みになっていた。StepSecurityの解析 つまり、アプリのHTTP通信に不審な処理がないかを探すだけでは足りない。導入時スクリプトを許す環境では、自分のアプリを起動する前にも、依存パッケージのコードが実行される。テストを始めるより前に、ビルド用の認証情報へ届く可能性がある。調べる対象にはインストールを実行した端末とCIランナーも入る。 npmで配られたもの 今回確認された役割 axios@1.14.1 1.x系列に悪意ある依存を追加したバージョン axios@0.30.4 0.x系列に同じ依存を追加したバージョン plain-crypto-js@4.2.1 導入時のスクリプトでRATを配備するための依存 StepSecurityの時系列では、悪性のAxiosが出たのは3月31日00:21 UTCと01:00 UTC。二つの系列への公開は39分の間に続いた。解析では、対応するコミットやタグはAxiosのGitHubリポジトリーに存在しなかったとも報告された。GitHubでソースを読んだことと、npmから取得した配布物を確かめたことは、同じ確認にならない。 解説図：Axiosのソースからimportされない依存でも、導入時スクリプトを許すとコードが動く。取得した事実と実行結果は分けて調べる。 消えているファイルを、安全の根拠にしない この事件では、実行後にドロッパーが自分のファイルを削除し、package.jsonを無害に見える内容へ差し替える動きも解析されている。あとからnode_modulesを見て不審なスクリプトがなかったとしても、それだけで過去の実行を否定できない。Aikidoが示した痕跡と対応 反対に、plain-crypto-jsのフォルダーを見つけただけで、RATの配備まで成功したと断定するのも早い。パッケージを取得・展開したこと、導入時スクリプトが実行されたこと、その後の不正プログラムが動いたことには段階がある。スクリプトを無効にしていた構成も含めて調べる必要がある。 確認するのは現在の依存ツリーとlockfileに加え、該当時期のインストール・ビルドの履歴、ネットワーク通信、使ったキャッシュだ。悪性バージョンを解決していたジョブが、どの環境で、どの秘密情報を使えたかを対応させる。npmから削除された後でも、以前に取得した配布物やキャッシュを調査から外さない。 当事者は端末と認証情報まで対応した メンテナーは4月2日に公開した事後報告で、端末を狙ったソーシャルエンジニアリングとRATによってnpmアカウントの認証情報へアクセスされたと説明した。実施した対応として挙げたのは、メンテナーの端末の初期化と、認証情報のリセットだった。また、OIDCを使う公開手順や、公開後に変更できないリリースの整備などを、進行中の改善として挙げた。メンテナーの事後報告 Vercelも3月31日、自社のビルド基盤から攻撃者の通信先への接続を遮断したと公表した。同社は自社システムへの影響はなかったと説明する一方、悪性バージョンをビルド環境で使った利用者には、クリーンな依存での再デプロイと、その環境に置かれていたAPIキー、DB認証情報、トークンなどの交換を案内した。Vercelの対応と利用者向けの案内 ここでAxiosだけを前のバージョンへ戻しても、既に読まれた可能性のある秘密情報は元に戻らない。利用者側でも、影響する実行を止めて記録を保全する。侵害が疑われる場合は、その環境から利用できた認証情報を、正常な別の端末から早急に失効・更新する。端末やランナーは既知の正常な状態から再構築し、新しい秘密は安全を確かめた復旧先だけへ渡す。GitHubのマルウェア情報も別の端末から秘密情報を更新し、パッケージ削除だけで関連する不正プログラムを除去できたとは考えないよう案内している。Axiosのマルウェア情報 依存の入れ直し、環境の復旧、秘密情報の処置を、それぞれの完了として確認したい。 解説図：悪性バージョンを除去する作業と、実行した環境・そこで利用できた秘密情報への対処を分ける。 lockfileとnpm auditにも、担当する範囲がある 当時の退避先は1.xが1.14.0、0.xが0.30.3だった。これは今回の悪性バージョンを避けるために案内された番号で、今後もそのまま固定し続ける推奨ではない。現在のサポートと後続の修正を確認して選ぶ。 再発を考えるとき、lockfileは必要な記録になる。ただし、悪性バージョンを含むlockfileを固定すれば、その内容を再現することにもなる。npm ciがlockfileどおりに導入することと、そこにある配布物が安全であることは別だ。依存名、解決されたバージョン、取得元と時点も確かめたい。npm ciの公式仕様 導入時スクリプトを抑える--ignore-scriptsも対策の一つになるが、既に実行されたコードを取り消す機能ではない。使っているnpmのバージョンと設定、必要な生成処理やビルドへの影響を確認して採用し、通常のアプリ実行時に動くコードへの対策まで済んだとは考えない。npm auditも既知の脆弱性情報との照合が中心で、「結果がゼロだから未知の改ざんもない」という保証にはならない。何を実行させるかという設定と、何を検知したかという結果を分けて使う。npm CLI v11のスクリプト抑止設定、npm auditの公式仕様 この事件で問われたのは、HTTPクライアントをどのバージョンへ直すかだけではなかった。いつもの依存を導入する作業で、どのコードが、どの端末の、どの権限を使うのか。Webサービスの公開前にも守る場所があることを、具体的に突きつける事例だった。 Chromeと運用者の端末 公開サーバーやCIを点検していると、作業に使うブラウザーは背景に回りやすい。でも、そのブラウザーから管理画面を開き、クラウドへログインし、リポジトリーの設定も変えている。サーバーの更新と並べて、普段使う端末側にも確認項目を持っておきたい。 悪用確認と分かっていない範囲 Googleは2026年6月8日のChrome Stable更新で、V8の範囲外メモリーアクセスに関するCVE-2026-11645を修正した。同じ告知の中で、実環境にexploitが存在することを認識していると説明している。修正前から悪用の情報がある問題として、手元の適用状況も確認したい事例だ。Googleの6月8日の告知 ただ、この告知だけでは、誰がどのページへ誘導され、どこまで侵害されたかという攻撃全体の詳細は分からない。V8の一つの不備を、そのまま端末のOS全体の権限取得と説明したり、利用者全員の被害へ広げたりはできない。ブラウザーの処理、ほかの防御、攻撃の組み合わせは区別する。 解説図：管理対象には公開サーバーへアクセスする人のブラウザーも含まれる。特定の攻撃連鎖を再現した図ではない。 ダウンロードと適用を確かめる このとき案内されたバージョンはWindows・Mac向け149.0.7827.102／.103、Linux向け149.0.7827.102だった。これは6月の修正境界で、10月末に149を導入する推奨ではない。10月29日の公式告知では、Stable／Extended Stableの配布バージョンは既に別の156系列になっている。番号だけを抜き出すと、古い安全情報を新しい推奨として伝えてしまう。10月29日の公式告知 Chromeの公式ヘルプでは、通常はバックグラウンドで更新が進み、適用には再起動が必要になると説明されている。「自動更新だから大丈夫」と記憶していても、ブラウザーを長く開きっぱなしにしていれば、再起動待ちの更新が残る場合がある。Google Chromeを更新する WindowsのChromeなら、メニューの「ヘルプ」から「Google Chromeについて」を開き、更新状況を確認する。再起動が案内されていれば作業中の内容を確認して再起動し、もう一度その画面で稼働しているバージョンを見る。企業の管理下にある端末では、配信設定や利用チャネルを管理する担当とも確認する。 解説図：更新が提供されたこと、取得されたこと、手元で適用されたことを分けて確認する。 サーバー担当だけで対応表を閉じると、この作業の持ち主が抜けることがある。開発端末、運用用端末、共有端末を誰が更新するのか。ブラウザーの更新履歴を、製品ニュースと自分の端末をつなぐ小さな確認として扱いたい。 関連事例を同じ箱に入れない 本文の12事例以外にも候補を比較した。ここでは対応の違いを読み取れる例を短く挙げる。同じ期間の話でも、CVEのあるソフトウェアの不備と、アカウントや配布物そのものの侵害は区別しておく。 公開する機能によって変わる条件 Cisco AsyncOSのCVE-2025-20393では、脆弱なバージョンに加えて、Spam Quarantineが有効で、インターネットから到達できることが攻撃キャンペーンの対象条件だった。初報の2025年12月17日と、2026年1月15日の修正版追加も区別する。初報の「修正なし」を、いつまでも現在の状態として読むと対応を誤る。Ciscoの公式告知 FortiWebのCVE-2025-64446では、防御製品自身の管理画面が問題になり、CISAは更新後にも不正管理者や設定変更を確認するよう案内した。Ivanti EPMMでは当初のRPMによる暫定修正について、製品を更新したあとに再適用が必要となる条件が示された。対策を入れた瞬間だけでなく、その後の変更で何が残るかも確認する話だ。CISAのFortiWeb告知、CERT-EUのIvanti EPMM勧告 期間の終わりに近い例では、Ivanti Connect Secureに関する10月30日の政府機関の追報がある。CVE-2026-104935、CVE-2026-111357、CVE-2026-118527の連鎖による悪用を伝え、対応先を更新している。10月13日の最初の告知だけを読んで作った表では、後から説明された連鎖全体を扱えない。単独の権限昇格の問題と、組み合わせた侵入の話も分けて読む必要がある。NHS Englandの追報、カナダ政府の更新 依存パッケージの侵害 2025年11月のShai-Hulud 2.0では、Postmanが依存パッケージから自動ビルドと公開権限へ影響が広がった経緯を公表している。トークンの失効、公開権限の絞り込み、認証方法の見直しなど、当事者が何を変えたかを読むと、依存の更新とビルドの権限がつながって見える。Postmanの原因分析 同社の説明では17の公開npmパッケージに波及した一方、PostmanのWeb・クライアントアプリや本番システムは感染しなかった。公開パッケージの侵害を、そのままPostman本体の侵害と読み替えない。 Shai-HuludやAxios、LiteLLMをCVE件数へ足して「脆弱性が何件起きた」と数えると、何を比較したか分からなくなる。共通して考えられるのは、信頼して実行したものが何へ届くかと、そこで利用できた秘密情報をどう扱うかだ。事件の分類は残したまま、運用上の問いを共有する方が理解しやすい。 npmの依存とは別に、Node.js本体も更新する 10月21日のNode.jsの修正には、Brotli展開処理のCVE-2026-111497もあった。攻撃者が渡した圧縮データをアプリがnode:zlibで展開する場合、メモリー破壊からクラッシュ、情報露出、コード実行につながる可能性がある。影響は22・24・26系列で、当該修正は22.23.4、24.22.1、26.12.1に入った。Node.jsを使うすべてのアプリが、この経路から攻撃を受けるという意味ではない。Node.jsの公式リリース Notionは同日、コア製品の修正と本番への展開を完了したと公表した。npmパッケージの更新だけで対応を閉じず、コンテナや実行基盤に含まれるNode.jsも確認する理由になる。これらの資料から実悪用までは確認できない。Notionの対応記録 優先順位を決めるための確認 12事例を並べると、深刻度の数字だけでは作業順を決められないことが見えてくる。認証前に届く処理なのか、特定の機能を有効にしたときなのか、編集権限が必要なのか。どこから届き、どの権限まで使えるかで、自分の環境への影響は変わる。 最初の確認では製品とバージョンを見つける。次に、該当する機能と設定、インターネットからの到達性を確かめる。そこへ実際の悪用の情報と、届く先のデータや認証情報を合わせると、先に扱う環境を絞りやすくなる。 解説図：同じCVEでも、自分の環境の機能・公開範囲・権限によって、対応を急ぐ理由が変わる。 まず担当と対象をつなぐ たとえば、外部公開したAIフローと、閉じた検証環境の同じ製品を一つの行にまとめると、どちらを先に直すかが見えにくい。公開していないから一切のリスクがない、という意味ではない。前提を分けて記録し、正規の利用者や、既に内部へ届いている相手からの経路も検討する。 確認結果を残すなら、「更新済み」だけで終わらせず、次のような項目を一緒に持ちたい。 残す内容 後で判断しやすくなること 製品名、系列、稼働しているバージョン 別系列や別製品の告知を取り違えない 該当機能、設定、公開範囲 成立条件と実環境を対応させる 対象CVE・事件名と参照した告知の更新日 追加修正や訂正が来たときに追い直せる 担当者と管理サービスの範囲 提供側と利用側の残作業を分ける 取得したログと保存先 更新や再構築のあとも調査へ戻れる 認証情報の交換範囲と完了確認 アプリの更新だけで作業を閉じない この一覧を作るために、最初から大きな専用システムが必要なわけではない。手元の運用記録へ、何を見て判断したかを残すところから始められる。次の担当者が同じ環境を見つけ、追加告知を照合できる記録にする。 修正版の数字を読む この記事でも、複数のバージョン番号が並んだ。数字には「初回の修正が入ったバージョン」「当時の一時的な退避先」「今、保守されている系列のバージョン」という違いがある。Trivyのような配布物の侵害では、配布元や取得時刻も加わる。数字が一つ一致しただけで、同じ状態とは判断しにくい。 たとえば、古い対応記事のバージョンへ更新して、その問題の修正境界を越えたとしても、あとで公表された別の問題が残っていることがある。逆に、メジャーバージョンを無条件に上げると、アプリや連携先との互換性の確認が必要になる。利用中の系列、サポート期間、後続の告知、推奨されるアップグレード経路を見て選ぶ部分だ。 だから運用記録には数字だけでなく参照した告知を残す。次に見直す人が「このバージョンにしたのは、この問題に対応するためだった」と読めれば、後続の修正との関係を調べ直せる。次の担当者にも更新の理由と残った確認を伝えられる。 止める機能と残す機能を決める 暫定策として「公開フォームを止める」「統計機能を無効にする」「SSOを止める」といった選択が出てくる。ただ、同じ停止でも影響は違う。問い合わせが受け付けられなくなるのか、分析を見られなくなるのか、管理者が装置へ入れなくなるのか。脆弱性の条件だけでなく、使っている機能から考えたい。 前回のWordPress対応で連絡窓口を残すことを優先したのも、止めるだけでは利用者の用事が消えないからだった。今回の事例でも、一時的に閉じるなら、代わりの連絡方法や管理経路、復旧後の確認方法までつなげて考えられる。 委託先やサービス提供元へ問い合わせる場合も、「影響はありますか」から一歩具体的にできる。対象の製品・バージョン・機能を示し、修正は提供側で適用するのか、利用者が更新するのかを聞く。侵害の可能性があるなら、ログをどこまで取得でき、どの認証情報が確認対象になるかも合わせて確かめる。 対応を終えるための確認 パッチを入れたことは、対応の中で確かに大きな結果だ。ただ、ここまでの事例では、パッチが直すものと、別に処置するものが具体的に分かれていた。既に作られた管理者、使える状態のセッション、持ち出された可能性のある認証情報は、アプリのバージョンが変わっただけでは消えない。 解説図：何を確認して対応を終えたのかを分けて残す。一つの成功を、すべての作業の完了へ広げない。 修正したことと動いていること Axiosのように導入時のコードが問題になった環境では、クリーンな依存へ戻したことに加え、実行した端末・CIと秘密情報への対処を確認する。Reactのようなデプロイを伴う環境なら、依存の変更が稼働中の成果物へ反映されたかを確認する。WordPressの自動更新なら、配信対象になっただけでなく、実際にバージョンが上がったかを見る。Chromeなら、取得した更新を再起動で適用し、表示されたバージョンを確かめる。 更新後に通常の機能が動くことも、利用者のために必要な確認だ。ログイン画面が開くだけでなく、公開フォームの送信、管理画面での更新、必要なバッチや連携まで、対策のために止めた機能と、その影響を受ける範囲が動くかを確かめる。変更した場所と使い続ける機能を結びつけておくと、確認する理由も説明しやすい。 侵害が疑われるときの扱い 悪用が確認された脆弱性を使っていたからといって、すべての環境が侵害されたと決めつけることはできない。同時に、不審なログをすぐ見つけられなかっただけで、未侵害と断定することもできない。保存期間やログの種類によって、調べられる範囲は変わる。 SiteGuardのように更新で痕跡が失われる可能性が示される場合は、その案内に沿って先に保存する。FortiCloud SSOで侵害の兆候があるなら、装置の設定と関連する秘密情報まで扱う。Metabaseなら接続先DBにも調査が続く。対象の環境に合わせ、製品ごとの公式な調査・復旧案内に沿って進める。 バックアップも取得した事実と復旧に使えることを分けて扱う。戻す時点が既に侵害後だったり、ファイルとDBの世代が合っていなかったりすれば、戻したあとに別の問題が残る。必要なデータが戻り、修正も適用され、正常な利用へ戻れる状態を確認して初めて、復旧について具体的に話せる。 読み続けるための小さな運用 一次資料は初報で終わらない。Metabaseのように侵害後の点検が案内されることもあれば、FortiCloud SSOのように対象範囲が訂正されることもある。Reactのように、当初のRCEとは別の追加修正が続くこともある。初報の数字を一度転記して終わると、こうした変更を拾いにくい。 使っている製品の公式セキュリティ情報を決めておき、緊急の連絡先と通常の見直しの機会を持つ。告知を読む人、稼働バージョンを調べる人、業務への影響を判断する人が別なら、誰が誰へ結果を伝えるかを決める。ひとりで運用していても、どの知らせを見たら何を確認するかを残しておくと、次のニュースから作業へ入りやすくなる。 PHP2Shellのときに感じた、設定を一つずつ調べ直すことで理解と意識が深まる感覚は、今回の12事例にもつながっている。製品名を増やして読むと、同じ「更新」という言葉の後ろに、違う仕事があることが見えてきた。 次に脆弱性のニュースを見たときは、自分が使っているかを調べ、その構成で問題が成立する条件を読み、修正を適用したあとに残る確認へ進む。すべてを暗記するより、この順で資料を読めるようになりたい。定期的に見直しながら、何を守り、何を使い続けるための設定なのかを、もう少し具体的に説明できるようにしていく。

出典 wordpress.org wordpress.org GitHub の告知 github.com/WordPress/wordpress-develop/security/a… Wordfence の件数（SecurityWeek） securityweek.com

WordPress Core Update Race: Potential Unauthenticated RCE During Full-Package Updates 1. Basic Information - Advisory: A race condition during core updates that could lead to remote code execution - Publisher: WordPress - Published Date: 2026-10-29 - Source: WordPress - Related Sources: SecurityWeek - Related Malware: None specified - Related Threat Actors: None specified - Related CVE: None specified - Related Products: WordPress Core - Severity: Medium 2. Executive Summary GHSA-4w3m-c66w-69mg addresses a potential unauthenticated remote code execution (RCE) path during a full-package WordPress core update. WordPress extracts files into a predictable, web-accessible staging directory; an attacker must win a race against that extraction. SecurityWeek reports probing and exploitation attempts, but the underlying primary observation material remains unverified. 3. Attack Flow Core Update Race Condition The following flow reconstructs the conditions for exploitation from the advisory. It does not describe a reproduced or confirmed successful compromise. 1. An administrator or automatic update initiates a full-package core update. 2. New files are extracted to a predictable directory within the web-served upgrade folder. 3. An attacker makes requests to the target path during a narrow race window to reach executable files. 4. Upon success, the attack proceeds to code execution with web server or PHP privileges. 4. Attacker Position and Execution Location - Unauthenticated attackers reaching the WordPress site upgrade path from the internet. 5. Victim and Administrator Perspective Victims - Typically asymptomatic, though successful exploitation may manifest as site defacement or suspicious redirects. Administrators - May observe upgrade path requests coinciding with core update timestamps, PHP processes, and file differences. 6. Success and Failure Conditions Success Conditions - A full-package core update is in progress on a vulnerable version. - The attacker successfully reaches the predictable or identified extraction destination, PHP execution is permitted, and they win the short race condition prior to cleanup. Failure Conditions and Mitigations - Update to the patched version for the active branch, such as 7.1.4, 7.0.8, or 6.9.11. - Restricting public access to the upgrade directory serves as a supplementary measure, but applying the core patch remains the priority. 7. Impact of Successful Exploitation - Remote code execution under the web server privileges. - Potential site defacement, credential or database access, and subsequent payloads. 8. Observable Logs - Email: None specified - Proxy / SWG / DNS: External requests to predictable paths such as /wp-content/upgrade. - Endpoint / EDR: PHP or web server child processes during core updates, execution within the upgrade directory, and unexpected files. - Identity / IdP: Because this can occur independently of administrative logins, verify unauthenticated requests. - SaaS / Cloud: Managed hosting update events and WAF logs. - Network: Path probing and subsequent outbound communications concentrated within the update window. 9. Assessing Attack Success - Attack attempts observed (success unconfirmed): Public information (secondary reporting): SecurityWeek reports probing and exploitation attempts. The underlying primary observation material and successful site takeovers remain unverified. Evaluation criteria: Correlate update timestamps, processes, files, and outbound communications (Scope: WordPress core update). 10. Investigation Playbook - Trigger: Upgrade path scans, PHP anomalies during updates, and unexpected files. - Initial checks: Verify the WordPress version, update method and timing, web root exposure, and log retention. - Endpoint: Preserve the upgrade directory, core file hashes, PHP processes, webshells, and outbound connections. - Identity / Cloud: Check the hosting control plane, administrator logins, and API tokens. - Follow-on: Inspect for webshells, database access, new administrator accounts, and modified plugins or themes. - Containment: Apply patches, isolate the site, redeploy a known-good core, and rotate credentials according to the impact. - Classification: Determine request arrival, race success, PHP execution, and persistence across separate stages. 11. Detection and Defense Ideas - Single events: Alert on external requests to the upgrade directory during core updates. - Time-series correlation: Correlate update initiation, path probing, PHP execution, and outbound connections. - Hunting: Review access logs and file integrity for the pre-patch update window. - Logging gaps: Detection is difficult without logs recording auto-update timestamps and temporary extraction paths. - Priority controls: Prioritize core patches, WAF visibility, file integrity monitoring, and the principle of least privilege. 12. Facts, Inferences, and Hypotheses Facts - During core updates utilizing full packages, WordPress extracted new files to a predictable directory within the web-served upgrade folder. - If an unauthenticated attacker won a brief race condition during extraction, they could reach the files being placed and achieve remote code execution. - The issue is addressed in WordPress 7.1.4 and backports down to the 4.7 branch. Fixes for older branches are provided as a courtesy, with ongoing support limited to the latest branch. - The GitHub advisory rates the severity as Low, and no CVE has been assigned. - SecurityWeek has reported scanning and exploitation attempts, but available information does not indicate successful site takeovers. Inferences - Although the attack window is narrow and reproducibility depends on the environment, automated scanners may repeatedly target update timing, making it valuable to review pre-patch upgrade logs and web requests. Hypotheses No additional hypotheses. Unconfirmed items are noted in "Open Questions and Limitations." 13. MITRE ATT&CK Mapping | ID | Technique | Confidence | Basis | | --- | --- | --- | --- | | T1190 | Exploit Public-Facing Application | High | Unauthenticated targeting of core update extraction race conditions exposed on public web paths. | 14. Open Questions and Limitations - The number of successful compromises, public PoCs, actual payloads, and reproducibility have not been confirmed. 15. Impact on SOCs and Organizations Organizations running WordPress should update to the patched version for their respective branch, and cross-reference core update timestamps with external requests to the upgrade directory, PHP file executions, and post-update file differences. Do not conclude that RCE occurred based solely on request logs. 16. Summary by Role - SOC: Correlate update window requests with PHP execution and file modifications. - Administrators: Update WordPress core to the patched version for the corresponding branch. - Users: Report any site display anomalies or suspicious redirects to administrators.

The change is subtle, but it makes the whole admin feel more polished. Try it out in 7.2-beta2, which is scheduled for Tuesday, October 27th. Developed in: wordpress-develop#11912

Script/style concatenation was only used in the login/admin for core's own assets. WordPress 7.2 will feature a more modern and performant approach where we prefetch the blocking scripts and styles that we know will be used on the next screen: wordpress-develop#13084

It's been a long road, but I think the WordPress core patch to eliminate script/style concatenation is ready to ship in 7.2! Goodbye load-scripts.php & load-styles.php (and all the headaches they have caused). This one PR will close 10+ Trac tickets: wordpress-develop#14463

It's been a long road, but I think the WordPress core patch to eliminate script/style concatenation is ready to ship in 7.2! Goodbye load-scripts.php & load-styles.php (and all the headaches they have caused). This one PR will close 10+ Trac tickets: wordpress-develop#14463