"Security Weekly 2026-W45: Symfony Ships 21 Advisories at Once"

This is the third issue of the NT IT security weekly, covering week 45 of 2026 (from 2 November). Data was read up to 6 November. (Two items were re-checked on 8 November before publication; each re-check is written into the section it belongs to.) One sentence ties this week's three stories together: the version number being right does not mean the hole was actually closed.

The urgent one first: if your site runs WordPress and is not yet on 7.1.4, update it now. The remote-code-execution flaw in the upgrade process that we reported last week entered the US CISA "Known Exploited Vulnerabilities" catalogue on 3 November, and the deadline CISA set for federal agencies is 6 November — the day this issue was started. More telling: on this entry CISA set the forensic-triage flag to Yes, and that flag is not on every entry.

The second story is this week's real batch: Symfony published 21 security advisories on 4 November, spread across 13 components, with fixed versions that differ by component (most are 5.4.56, 6.4.50, 7.4.23 and 8.1.11). The count is not the point. The point is that six of them carry the words "Incomplete Fix" in the project's own title — an earlier patch did not finish the job, and each one names the older id it is completing — while a seventh is more direct still: it is a regression introduced by a previous patch. Last week we reported that Symfony had corrected a "fixed" claim it made in May. This week the same shape appears seven more times.

The third story is Chrome 157 (promoted to stable on 3 November), where the official sentence reads "This update includes 213 security fixes." The number looks alarming, but it accumulated across a whole major release cycle, so it cannot be compared directly with last week's "Chrome 156 fixed 21 issues". Section three explains why.

How to read this weekly

• Every item is labelled by source tier: [Official] means the vendor, project or government agency said it themselves; [Research/Media] means a security firm or outlet said it, and those come after the official ones. Where the two disagree, we print both and pick neither.
• Patch version numbers are copied from the official advisory, never from a second-hand roundup. Numbers we counted ourselves are labelled as ours.
• You need to know which version you are running before these numbers mean anything. How to check, and where it most often goes wrong, is in Security Basics 01｜An advisory just landed: how do you know whether it affects you
• Where advisories live and who should be watching them is in Security Basics 06: Where to read security advisories, and how to confirm someone is watching them

1. The WordPress upgrade flaw is now officially under attack

[Official: US CISA] CVE-2026-119977 entered the CISA Known Exploited Vulnerabilities (KEV) catalogue on 3 November. We read the data file CISA publishes itself, catalogue version 2026.11.04, which held 1,768 entries at the time. CISA's own description: WordPress core contains a time-of-check time-of-use (TOCTOU) race condition that could allow unauthenticated attackers to execute code on the server during the upgrade window, because full-package core upgrades use predictable, web-accessible staging paths.

Three details are worth reading separately:

• The deadline is 6 November 2026. KEV deadlines bind US federal agencies, not companies in Taiwan. But the deadline is a judgement you can borrow: the official body gave its own people three days, which says it did not consider this something to schedule for next month.
• The forensic-triage flag on this entry is Yes. On the other entry added the same week (CVE-2024-27834, Apple, added 4 November, deadline 18 November) that field is No. The difference: the recommended response here is not only "update", it includes going back to check whether you were already hit.
• The fix is 7.1.4, released 28 October, and as of 6 November it is still the current release. We read the current version back from WordPress's own version-check endpoint: 7.1.4, with no newer patch release, so there is nothing to wait for.

[Official: WordPress] The WordPress 7.1.4 announcement lists this as the first item in its security fixes: "A weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window, reported by Umut Bayram." The same release also fixed several stored XSS issues in the Interactivity API, a stored XSS in Customizer selective refresh, a stored XSS in the Categories block, and a stored denial-of-service issue. The announcement's own wording is "Because this is a security release, it is recommended that you update your sites immediately."

The official announcement carries no CVE id and no affected-version range. We looked those up elsewhere: the id came from CISA and NVD, and NVD scores the flaw at CVSS 3.1 8.1 (HIGH), listing affected branches from 4.7 upward. So "I only read official announcements" would cost you the severity and the range on this one — not because the project failed, but because the two kinds of source carry different jobs.

2. Symfony's 21 advisories, seven of them about an earlier patch

[Official: Symfony] On 4 November 2026 Symfony published 21 security advisories at once. Both official channels agree on the number: the November 2026 archive on symfony.com carries 21 advisory posts, and the Packagist security advisories API returns 21 for symfony/symfony with a report date of 2026-11-04.

First, a trap we fell into ourselves, because you may well be using the same method to follow advisories: those 21 posts come under two different URL shapes. Sixteen are at /blog/ghsa-…; the other five are at /blog/cve-…. On our first pass we matched only the ghsa shape, counted 16, and concluded that the official blog carried five fewer than Packagist. That conclusion was wrong; our matching had missed the other URL shape.

The trap is worth writing down because it is not specific to us: as soon as you filter advisories by URL pattern, feed-title prefix or keyword, one vendor changing a naming convention costs you a whole subset, and nothing on your screen turns red — you simply see "that was all there was this week".

One batch of 21, four official datasets, four different answers

Having recounted, we kept digging, and what we found matters more than whether the count was right: these 21 advisories look different in four official channels, and whichever one your tooling reads is the version you see.

Row by row, because each one means something different:

• Five CVE ids versus nine: the extra four are real. GitHub's repo advisory dataset carries four ids the others do not: CVE-2026-121373 (HtmlSanitizer meta refresh), CVE-2026-121949 (HtmlSanitizer srcset), CVE-2026-123119 (NoPrivateNetworkHttpClient) and CVE-2026-123125 (the Ip validation constraint). We checked each at NVD and all four are there (registered on 4 and 5 November). On 6 November all four sat at status Received — registered, not yet analysed, so none of them carried a CVSS score at that point. Re-checked on 8 November before publication, all four now carry scores (status is now Awaiting Analysis): CVSS 4.0, in the order listed above, is 5.3, 2.3, 2.3 and 6.3; CVE-2026-121949 and CVE-2026-123125 additionally carry CVSS 3.1 scores of 5.4 and 6.5. Do not compare the two scoring systems against each other: CVE-2026-121949 is 2.3 (LOW) under 4.0 and 5.4 (MEDIUM) under 3.1 — the same flaw lands in different severity bands. The two scores also come from different sources, and the NVD response gives only a source identifier, not an organisation name, so we do not put a name to it. Neither symfony.com nor Packagist carried those four when we looked.
• Only the GitHub dataset gives a severity, and that is of practical use when scheduling. Its distribution: 5 high, 10 medium, 6 low and 0 critical (21 in total). Nothing in this batch is marked critical — which is the basis for "schedule it, but do not drop everything today", and that basis is not readable on the official blog or on Packagist.
• GitHub's global advisories API returns none of them, and asking for each id individually returns Not Found. It is a different dataset from the project's own repo advisories (when we measured, the composer ecosystem in the global set stopped at the end of October). So "I checked GitHub's advisory API and there was nothing" depends entirely on which one you asked.
• One more small trap: the five posts titled by CVE on the blog also have their own GHSA ids on GitHub (CVE-2026-118513 is GHSA-5w3m-mfwg-9f8r, for instance), and symfony.com never shows that set of ids. One flaw with two names in two places is easy to reconcile as two separate items.

The point is not which dataset is correct — all four are official and none of them is lying; they simply record different fields and refresh at different speeds. The sentence to keep is this: what actually reconciles is comparing totals across two or more sources, not whether you are subscribed. And if your scanner reads one source, the severities and ids it shows you are that source's version, not the whole picture.

21 advisories across 13 components

This is not one component failing repeatedly; it is a sweep. Read post by post, the distribution is HTTP Foundation 3, Serializer 3, HTML Sanitizer 3, HTTP Client 2, Security HTTP 2, plus one each in Config, JSON Path, YAML, HTTP Kernel, Filesystem, Routing and Validator, and one covering both Framework Bundle and HTTP Foundation.

The fixed versions are not the same for every advisory, and that is easy to miss. Most say 5.4.56, 6.4.50, 7.4.23 and 8.1.11; but the three HTML Sanitizer advisories are fixed only from 6.4.50 onward (the 5.4 line does not carry that component), and the JSON Path one only in 7.4.23 and 8.1.11. So "we are on the latest patch release" has to be checked against the components you actually use, not against one generic set of numbers.

Six advisories the project itself labels "Incomplete Fix", each naming the older id

The most useful part of this batch for a non-technical decision-maker is not the count but the nature of these six. They are not newly discovered design flaws; they are cases where the earlier fix did not close the issue — and Symfony puts that in the title rather than burying it:

• CVE-2026-118513 (Security HTTP): X509 authenticators split DN values on escaped commas and bare slashes. The title reads Incomplete Fix for CVE-2026-45063.
• CVE-2026-118514 (HTTP Foundation): HEAD requests bypass the methods option of access_control and firewalls. The title reads Incomplete Fix for CVE-2026-45075.
• CVE-2026-118517 (HTML Sanitizer): host allow-lists bypassed via malformed URL authorities. The title reads Incomplete Fix for CVE-2026-45066.
• GHSA-c7hm-wqwp-f9v8 (HTTP Client): NoPrivateNetworkHttpClient did not pin the IP of cached hosts. The title reads Incomplete Fix for CVE-2024-50342 — it completes a 2024 patch. The design resolves a host, checks whether the IP is private, then hands that IP to the underlying client; but it only handed it over on the first resolution. Later requests to the same host resolved again, so the IP checked and the IP connected to could differ.
• GHSA-cpww-5vpx-72x7 (JSON Path): a query can hold a PHP process. The title begins Incomplete Fix for CVE-2026-45756. The explanation is specific: the previous fix lowered pcre.backtrack_limit to 10000 around each match, but that limit applies to one starting position, not to one call, so the cost is paid again for each byte of the subject.
• GHSA-wm2w-4mgj-vw33 (HTML Sanitizer): meta refresh handling covered only part of the grammar browsers accept. The title reads Incomplete Fix for CVE-2026-48761.

A seventh is not an unfinished fix but a regression the previous fix created (GHSA-3h27-hjv7-fqjx, HTTP Foundation): path rules can be bypassed by appending to the script name. The official description states that since the fix for CVE-2025-64500, Request::getPathInfo() strips the script name from the start of the URL, and does so even when the script name is only the start of a longer path segment. With SCRIPT_NAME set to /index.php, a request to /index.phpadmin gets the path info /admin and is routed accordingly. The affected range is therefore not "all older versions" but from 5.4.50, 6.4.29 and 7.3.7 onward — meaning the people who update diligently are the ones exposed here.

Put together, those seven make one sentence worth repeating to a business owner: "we already updated last month" does not answer "is that hole closed". Patches have bugs too, and a regression introduced by a patch usually only affects the people who already applied it. That is also why inspection needs a fixed rhythm rather than one update and a closed ticket.

This batch changes behaviour, not just internals

One advisory fixes "programmatic logins skip the checkPostAuth() method of user checkers" (GHSA-8f57-m8wj-x65w, Security HTTP). In its Resolution section the project states the side effect plainly: after the fix, an exception thrown by checkPostAuth() now comes out of Security::login() and authenticateUser(). The inline-fragment advisory likewise notes that code reading the main request while a sub-request is in flight will behave differently. So this batch is not one to apply straight to production and walk away. If you have automated tests, run them first, especially the paths that log users in programmatically: registration, password reset, email verification.

3. Chrome 157: the official number is 213, and it needs reading carefully

[Official: Google] The desktop stable post of 3 November states, verbatim, "The Chrome team is delighted to announce the promotion of Chrome 157 to the stable channel for Windows, Mac and Linux." The versions are 157.0.8103.38/.39, and the security line reads "This update includes 213 security fixes."

The severity breakdown below is ours, counted by hand; Google published no summary: 7 Critical, 77 High, 75 Medium and 54 Low. They add up to exactly 213, matching the official sentence, and that cross-check is the only reason we are willing to print them.

Do not compare 213 with last week's "Chrome 156 fixed 21 issues". 157 is a major-version promotion and clears everything accumulated across a development cycle; 156's update was a minor one inside the same major version. The two numbers measure different spans of time, and comparing them produces a conclusion — "Chrome got ten times worse in a week" — that does not exist.

Two things you can act on:

• This post mentions no exploitation in the wild. We searched the full text for the three phrases Google normally uses — in the wild, exploit exists, actively exploited — and none appears. So it is urgent, not wake-up-at-night urgent.
• A Chrome update is not live because the vendor shipped it. The post itself says "This will roll out over the coming days/weeks." What a company needs to confirm is whether people have actually restarted their browsers, not whether Google has published.

One more detail, listed because it is in the official text and because it bears on where this trade is going: of those 213 fixes, 14 are credited to researchers Google labels as being at Anthropic, with the words "assisted by Claude" (Xinyang Ge and Vlad Stolyarov), including one of the seven Critical items (CVE-2026-121035, a use-after-free in Prerender). In the same week, the WordPress 7.1.4 credits list an XSS "reported by Anthropic". Two independent official sources recorded the same thing in one week: AI is now part of the work of finding vulnerabilities. We draw no conclusion from it — it does not mean fewer flaws ahead, nor more attacks — but it does suggest the volume of advisories is unlikely to fall, and that "is someone watching this regularly" becomes a question about staffing rhythm rather than enthusiasm.

4. Next.js patched cache leaks the same day, one of them a follow-up

[Official: Next.js] On 3 November, 16.4.5 and 15.5.29 were released. Both release notes open with "This release contains security fixes for the following advisories:", and every advisory sits under Moderate, with no higher tier listed.

16.4.5 covers 7 advisories, 15.5.29 covers 3 (a subset of the first). The titles alone show they are one family of problem — caching crossing a boundary it should not: cross-tenant disclosure in use cache when called through unstable_cache; a cache leak across root param values in nested use cache functions; cache poisoning of shared fallback shells in Cache Components via request-supplied placeholder route params; cross-user cache disclosure and poisoning with binary arguments. The other three — the ones 15.x also carries — are cross-client response injection and disclosure in self-hosted apps forwarding fetched responses, an SVG rejection bypass in image optimization, and HttpOnly cookie exposure through an internal response header on Edge runtime routes.

One official title ends, verbatim, with "(follow-up)" — the cache leak across root param values is the sequel to an earlier fix. That is the third vendor this week with the same shape.

One practical note: these all assume your system shows different content to different users and has caching switched on. A purely static marketing site is unlikely to be affected. Anything with logins, members or multiple tenants should schedule this batch.

5. Two already-announced batches next week, worth putting in the calendar now

• [Official: Node.js] Node.js has pre-announced security releases for "on or shortly after, Wednesday, November 11, 2026", covering the 26.x, 24.x and 22.x lines. The announcement states that the highest severity in each of the three lines is HIGH. It also includes a line worth forwarding to everyone: "It's important to note that End-of-Life versions are always affected when a security release occurs." End-of-life versions are affected every time, because nobody is going to publish a patch for them. The announcement does not say how many issues will be fixed.
• [Official: Oracle] The next Critical Security Patch Update is Tuesday 17 November 2026, and Oracle states that a pre-release announcement is published on the preceding Thursday (12 November). Oracle now runs two schedules: the quarterly Critical Patch Update (third Tuesday of January, April, July and October; next on 19 January 2027), and a Critical Security Patch Update on the third Tuesday of February, March, May, June, August, September, November and December. Confusing the two leads to "Oracle has nothing this quarter".

Neither is a "do it now" item, but both are schedulable in advance — and the reason inspection gets dropped has never been a lack of time. It is not being in the calendar.

6. Sources we checked and found nothing new in

This section carries the same weight as the ones above: only by naming what you checked and cleared do you know what is left. Each line below is something we actually read this week; the parenthesis gives the last entry we saw.

• PHP [Official]: no security update this week. 5 November brought only 8.6.0 RC5, a testing release. The last security advisory was the 21 October batch (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35), covered in issues one and two.
• Laravel [Official]: 13.40.0 shipped on 3 November with no security entries in the release notes (we searched the whole text for "security" and found none). The most recent advisory for laravel/framework on Packagist is dated 23 October.
• GitLab [Official]: no new batch this week. The last one was 29 October (19.5.3 / 19.4.5 / 19.3.7 / 19.2.10 / 19.1.10 / 19.0.1). This also answers the open question we left last week: last week we wrote that we could not confirm whether GitLab had a new batch. As of 6 November, it did not.
• Mozilla [Official]: no new advisory this week. The latest is MFSA 2026-123 of 27 October (Firefox 159).
• Go [Official]: no new release this week. 1.27.3, which carries security fixes to crypto/x509, was released on 19 October and falls outside this week's window.
• Oracle [Official]: no new advisory this week; the October batch's last revision is Rev 2, dated 26 October.
• Composer (ca-bundle) [Official]: no new release this week; the last is 1.6.1 of 29 October.
• Electron [Official]: releases went out on 3 and 4 November (45.2.3 / 45.2.2 / 44.10.2 / 43.8.7), but the release notes describe crash fixes and backports from upstream (Chromium, ANGLE, FFmpeg and others), and list no security advisories. So it does not count as a security update this week — though if your desktop app is packaged with Electron, those 213 Chrome fixes will arrive gradually as backports.

7. What we could not find, or did not read this week

This section is deliberate. A weekly that prints only what it saw leaves readers believing "that was all there was" — and only the person writing it knows what was missed.

• GitHub's changelog: not read on 6 November, read in the pre-publication re-check. That day DNS resolution for github.blog failed from this machine; the page did not return an error — that is our environment, not GitHub being quiet. On 8 November resolution worked and we read the 10 most recent changelog entries (4 to 7 November): none of them is a vulnerability advisory requiring a patch; they are feature changes (for example secret scanning detector updates on 5 November and CodeQL 2.27.4 on 4 November). We read only those 10 entries, so we cannot say whether anything landed on 2 or 3 November.
• Singapore CSA's advisory page: not read this week. It returned a 301 redirect that we did not follow through.
• An official severity summary for Chrome's 213 fixes: not found. The post labels each item Critical / High / Medium / Low but gives no totals anywhere. The breakdown in section three is our own count, printed with its provenance rather than dressed up as Google's.
• The six tier-two sources — Tenable, Sansec, Socket, StepSecurity, Snyk and Checkmarx — were not read at all this week. This is the same gap as last week, and we did not close it. It means that if a flaw was discussed only by research firms this week and no vendor had published, this weekly cannot see it.
• Three leads from another line, all of them closed out this issue — and one of them rewrote section two. (1) It first said "this Symfony batch is 22 advisories" and corrected itself to 21 the same day, matching the 21 we counted independently in each of two channels; that correction is also what sent us back to recount and find our own miscount of 16. (2) It said nine of the batch carry CVE ids and named four of them. On our first pass we could not find those four on Packagist, on symfony.com, or in GitHub's global advisories API, so we kept them out of the conclusions. It then gave us the exact source — the repo-specific endpoint repos/symfony/symfony/security-advisories on GitHub — we queried it ourselves, confirmed all four, and picked up the severities that only that dataset carries. So the comparison table in section two is the product of that exchange, not of our own digging alone. (3) An advisory id said to affect Laravel 13.x still does not check out (GitHub's global API returns Not Found, Packagist has no November entry for laravel/framework), so it stays out of the conclusions. This paragraph stays in because of what it demonstrates: write "could not verify" when you could not — but ask for the source before concluding. Our first "could not find it" was correct, and so was the second pass's "confirmed"; all that separated them was the right endpoint.
• LiteLLM's 1.108.0 (4 November) release notes contain the word "security", but we did not verify the items. It ships several versions a week, and separating which line is a security fix takes a pass of its own. We did not do it this issue.
• The KEV data file only runs to 4 November (version 2026.11.04), so whether anything was added on 5 or 6 November is outside what this issue can see.

There is also a structural gap that holds every week: this source list was not derived from the packages our clients actually run. It grew out of two teams' experience. Making it genuinely cover your system starts with having your own technology inventory — which is the first thing a system health check produces.

Three questions to put to whoever runs your systems

• Which WordPress version are we on? If it is not 7.1.4 or newer, the follow-up is "when do we update, and who does it". This one has officially confirmed exploitation behind it, not a theoretical risk.
• Have the Symfony components we actually use all moved to a patched version? (Most are 5.4.56 / 6.4.50 / 7.4.23 / 8.1.11; HTML Sanitizer from 6.4.50; JSON Path only 7.4.23 and 8.1.11.) If they already had, ask one more: "did the path-rule bypass regression actually hit us?" That one only affects systems already on 5.4.50 / 6.4.29 / 7.3.7 or later.
• Who is handling next Wednesday's Node.js batch? The date and the top severity are already published, so this question tests process, not expertise: is anybody reading the pre-announcements, rather than waiting for the incident.

NT IT Co., Ltd. came out of custom software development and now works on keeping AI systems maintained after launch. We publish this weekly every week, and long-term maintenance is exactly the part this article cannot finish: security updates on a fixed rhythm, urgent flaws handled separately, and somebody verifying before and after an upgrade. If you are not sure which technologies your system uses, or whether anyone is watching the advisories that match them, start with a system health check: Book a system health check

Sources for this issue

Tier 1 (official): CISA Known Exploited Vulnerabilities catalogue data file https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json ; WordPress 7.1.4 announcement https://wordpress.org/news/2026/10/wordpress-7-1-4/ ; WordPress version-check endpoint https://api.wordpress.org/core/version-check/1.7/ ; NVD entry for CVE-2026-119977 https://nvd.nist.gov/vuln/detail/CVE-2026-119977 ; Symfony security advisories category https://symfony.com/blog/category/security-advisories ; Symfony November 2026 archive https://symfony.com/blog/archives/2026/11 ; Packagist security advisories API https://packagist.org/api/security-advisories/ ; Chrome desktop stable post https://chromereleases.googleblog.com/2026/11/stable-channel-update-for-desktop.html ; Next.js 16.4.5 https://github.com/vercel/next.js/releases/tag/v16.4.5 and 15.5.29 https://github.com/vercel/next.js/releases/tag/v15.5.29 ; Node.js November 2026 security release pre-announcement https://nodejs.org/en/blog/vulnerability/november-2026-security-releases ; Oracle security alerts index https://www.oracle.com/security-alerts/ ; PHP 2026 news archive https://www.php.net/archive/2026.php ; Laravel 13.40.0 https://github.com/laravel/framework/releases/tag/v13.40.0 ; GitLab patch release feed https://docs.gitlab.com/releases/patch-releases.xml ; Mozilla security advisories https://www.mozilla.org/en-US/security/advisories/ ; Go release history https://go.dev/doc/devel/release ; Electron releases https://github.com/electron/electron/releases .

Tier 2 (research/media): this issue cites no tier-two source, because none was read this week (see section seven).