Category: Security

Here is the part that should bother you: there is no new patch to wait for. On Wednesday, November 4, CISA added an Apple flaw, CVE-2024-27834, to its Known Exploited Vulnerabilities catalog — the list of bugs it has evidence are being used in real attacks. Apple fixed this one in May 2024. If your iPhone, iPad, or Mac is current, you have been protected for about eighteen months. If it is not, a state-linked campaign has been looking for you.

What happened

The flaw sits in WebKit, the engine behind Safari. It is classed as improper authentication, and in plain terms it lets an attacker who already has arbitrary read and write access bypass Pointer Authentication. Pointer Authentication is a hardware-backed check on Apple processors that signs memory pointers, so corrupted memory is harder to turn into running code. Bypassing it does not break into a phone by itself. It removes a lock that keeps a first break-in from becoming a full exploit.

That is exactly how it is being used — as one link in a chain. The CISA listing follows a report from the security firm Sekoia on a campaign it calls Poisoned Source. Sekoia attributes the activity, with moderate to high confidence, to APT29 — also known as Cozy Bear and Midnight Blizzard, a group affiliated with Russia’s Foreign Intelligence Service. I am repeating that as Sekoia’s assessment, not as a proven fact, because attribution is an assessment and this one is worded that way by the researchers themselves.

According to Sekoia, as reported by The Hacker News and SecurityAffairs, the attackers reached visitors three ways: compromised legitimate websites, fake sites masquerading as popular websites, and a supply chain attack on Plerdy SEO Tracker, an analytics script other sites load. A visitor’s device was profiled first, then malicious JavaScript triggered a chain combining a WebKit remote code execution flaw with this bypass. The payload was information-stealing malware built to harvest browser cookies and device data. Steal the cookies, and you can often reuse someone’s logged-in sessions without learning their password.

Apple addressed the flaw back in May 2024 with improved checks in iOS 16.7.8 and 17.5, iPadOS 16.7.8 and 17.5, macOS Sonoma 14.5, tvOS 17.5, watchOS 10.5, and Safari 17.5. The bug had been demonstrated as a zero-day at the Pwn2Own Vancouver contest in March 2024. None of that is new. What is new is CISA saying, on November 4, that it is now being exploited, and giving federal agencies until November 18, 2026 to make sure they have remediated it.

How bad is it, honestly?

The score will mislead you if you let it. CISA and the reporting put CVE-2024-27834 at 5.5 out of 10 — medium severity. Read alone, that sounds like something you can defer. Read correctly, it is a chain component: it needs another flaw to give the attacker read and write access first, and then it makes that access far more useful. Exploit chains are built out of exactly this kind of medium-rated piece, because the pieces are what the defense was counting on to stop the chain.

Now the other side, because I will not hype this. If your Apple devices are up to date, this flaw is already closed for you, and has been since 2024. This is not a new hole in current iPhones. The risk is concentrated in the long tail: older phones and tablets that stopped being updated, a Mac deferring its update for months, a spare device in a drawer that still signs into email. Those are the devices a watering-hole campaign like this is built to catch, precisely because their owners think of them as harmless.

There is also a website lesson here. One delivery route was a third-party analytics script loaded by other people’s sites. Every tracker you add to a website is code you are asking your visitors to trust. If you run a site, that supply chain is part of your security.

What to actually do

First, update every Apple device you own, not just your main phone. On iPhone and iPad, go to Settings, then General, then Software Update, and install what is offered. On a Mac, use System Settings and Software Update, which also brings Safari current. Do not aim for the old fixed versions I listed above — those are the floor from 2024. Install the latest version your device is offered.

Second, turn on automatic updates and leave them on. This campaign worked, to the extent it worked, against devices that had missed patches that already existed. Automatic updates are the boring control that closes that gap while you sleep.

Third, decide about devices that cannot update anymore. If a phone or tablet can no longer get current Apple software, do not keep using it for email, banking, or anything signed in — a stolen cookie does not care that the device is “just a spare.” Retire it or keep it off your accounts.

Fourth, if you run a website, audit its third-party scripts. Remove trackers you no longer use and know which ones remain, because the Plerdy route is the general pattern: compromise one widely loaded script, and you reach every site that loads it.

My bottom line: do not panic about a 5.5, and do not shrug at it either. Check your oldest Apple device today. That is where this one lives.

Sources: The Hacker News, “Hackers Exploit Patched Apple Flaw to Deliver Info-Stealing Malware, CISA Says” (November 5, 2026) — thehackernews.com/2026/11/hackers-exploit-patched-apple-flaw-to.html; SecurityAffairs, “U.S. CISA adds Apple flaw to its Known Exploited Vulnerabilities catalog” (November 5, 2026) — securityaffairs.com; CISA Known Exploited Vulnerabilities Catalog, entry for CVE-2024-27834 (added November 4, 2026, due November 18, 2026) — cisa.gov/known-exploited-vulnerabilities-catalog.

If you run a Rails app that takes uploads, check your version today. This morning, November 4, the Rails team released two security updates — 8.1.4.1 and 8.0.5.2 — fixing 21 security issues at once. At the top is a critical flaw in Active Storage, the part of Rails that handles uploads, rated 9.8 out of 10.

What happened

The worst issue is tracked as GHSA-f3w6-w445-fwh9. It has no CVE number yet — the GHSA identifier is the one to use. The Hacker News, summarizing the advisory, describes it this way: an unauthenticated attacker can write arbitrary files on an app’s server by uploading a crafted file, if the app processes uploads using ImageMagick.

The mechanism, in plain terms: ImageMagick picks a format handler — it calls them coders — based on a file’s content, not just its extension. Some coders act on other files named inside the image instead of on the image itself. Active Storage put no limits on which coders an upload could use, so the server’s own ImageMagick policy was the only limit. According to the fix commit described by The Hacker News, an uploaded SVG reached ImageMagick’s MSL coder through the analyzer — MSL is a scripting coder that reads and writes files named by its script.

Two details make this worse. First, the analyzer runs when a file is attached. Attaching the upload is enough; the app does not have to make a variant, a preview, or an explicit analyze call. Second, if your app stores attachments with Active Storage’s Disk service, an attacker may also be able to read any file the app can read. Rails says those files typically include the app’s secret_key_base and its credentials for other systems, and reading them may in turn allow remote code execution or movement into those systems.

The same releases fix a second Active Storage flaw, GHSA-v924-7rp8-4mxh, rated High at 8.8, involving possible file read and remote code execution in video previews, analysis, and image processing. The announcement also lists a Strong Parameters bypass, IP spoofing in 8.1 only, several cross-site scripting flaws, denial-of-service issues, and session handling problems among the 21.

How bad is it, honestly?

Bad for the apps it hits, and narrower than the headline suggests. An app is affected only if all three are true: it uses ImageMagick for Active Storage — the :mini_magick processor, the default for apps on load_defaults 6.1 or earlier; its ImageMagick policy does not already block the coders involved — Rails says the policies Debian and Ubuntu ship do not; and it accepts uploads from untrusted users.

If your app uses the vips processor — the default from load_defaults 7.0 on — this attack path is not yours. You still need the update for the other 20 fixes, but you are not standing in front of the 9.8.

Now the part I will not hype. The advisory, as reported, does not say this flaw has been exploited in the wild. Rails said one attack chain was reported to it, and that it does “not assume it is the only one that exists.” This is a researcher-found bug — reported through HackerOne by RyotaK of GMO Flatt Security — patched on disclosure, not a CISA known-exploited listing like the WordPress flaw I wrote about on Monday. Patch it like it matters, because a public advisory is also a map for attackers, but do not tell yourself you have already been breached.

The calendar problem

Security support for the Rails 8.0 series ends on November 7, 2026 — three days after this release. The announcement says older versions are unsupported and recommends upgrading to at least the 8.0 series. If you are on 8.0, 8.0.5.2 is very likely your last safety net, and your real job this month is moving to 8.1. Older than 8.0, no fixed version is coming at all.

What to actually do

First, upgrade to Rails 8.1.4.1 or 8.0.5.2. If your app uses :mini_magick, you also need mini_magick 5.1 or later, or the app will raise an error at boot.

Second, verify the new protection actually reached your app. The fixed versions ship a restrictive ImageMagick policy blocking the MSL coder, coders that read or delete other files, coders that fetch remote or local references, the Ghostscript-backed coders and the gs delegate, and @filename indirection. The Hacker News lists the check from the Active Storage guide: run bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }' and confirm the policy is loaded. An app that replaces MiniMagick’s environment after boot, uses GraphicsMagick, or has a permissive rule in the server’s own policy can quietly undo it.

Third, if you cannot upgrade today, use Rails’ workaround: copy the shipped policy file’s rules from the activestorage gem into ImageMagick’s system policy, at minimum blocking the MSL coder, the Ghostscript coders, and the gs delegate.

Fourth, if your app stores attachments on disk, think about secrets. If that read path was open to untrusted uploads, change secret_key_base and every other secret the app can read — master key, encrypted credentials, storage and database credentials, and third-party tokens — and do not keep an exposed secret as a fallback.

My bottom line: check which processor you run, upgrade before the weekend, confirm the policy loaded, and if you are still on 8.0, start the move to 8.1 now. November 7 is three days away.

Sources: Ruby on Rails, “Rails security releases: 8.0.5.2 and 8.1.4.1” (November 4, 2026) — discuss.rubyonrails.org/t/rails-security-releases-8-0-5-2-and-8-1-4-1/91802; The Hacker News, “Critical Rails Flaw Lets Attackers Write Server Files via Crafted ImageMagick Uploads” (November 4, 2026) — thehackernews.com/2026/11/critical-rails-flaw-lets-attackers.html.

Most months, Android’s security bulletin is a list you skim. This month it is a list you act on. Google’s November update patches more than 200 vulnerabilities, and roughly two dozen of them are rated critical.

What happened

Google announced the November 2026 Android security updates on Monday, according to SecurityWeek. The fixes arrive in two parts. The first part shows up as the 2026-11-01 security patch level and resolves 119 defects across Android runtime, Framework, and System. Framework took the largest share, with 65 fixes, followed by System with 53, plus one high-severity information disclosure fix in Android runtime.

The second part shows up as the 2026-11-05 security patch level and fixes another 97 bugs in the Kernel and in components from Arm, Imagination Technologies, MediaTek, Unisoc, and Qualcomm. Google notes that a patch level of 2026-11-05 or later addresses all of the issues in this month’s bulletin. That distinction matters, and I will come back to it.

The worst of it

The most severe flaw, according to Google’s bulletin, is in Framework and is tracked as CVE-2026-58868. Google describes it as a critical vulnerability that could lead to remote code execution with no additional execution privileges needed, and with no user interaction needed for exploitation. CyberInsider reports that Google lists updated releases for Android 14, 15, 16, 16 QPR2, and 17 for this flaw.

It is not alone. Two more critical remote code execution flaws, CVE-2026-58876 and CVE-2026-58936, affect the System component across the same releases. The 2026-11-05 level adds critical fixes in the kernel as well, including issues affecting Bluetooth, protected virtualization, and device handling, along with critical flaws in MediaTek modem components and a Qualcomm closed-source component.

One entry will catch the eye if you follow Android news. CVE-2026-58882 is the flaw that has been called the “SMS of Death.” Google now lists it as a critical System flaw under the 2026-11-01 patch level, covering Android 14 through 17. As CyberInsider explains, a malformed message can crash the phone process and terminate active calls, without the message ever appearing in an inbox or needing to be opened. That is a denial-of-service bug, not a takeover — but a bug that can cut a call is not a minor bug.

How bad is it, honestly?

Serious enough to update promptly, not serious enough to panic. Start with what is not in the reporting I read: neither SecurityWeek nor CyberInsider reports active exploitation of these November flaws in the wild. That is different from the actively exploited firewall and VPN flaws I have written about in recent days, where attackers were already using the bugs before most people patched.

What makes this month worth moving on is the shape of the worst bugs, not a confirmed attack. Remote code execution that needs no tap, no open, and no extra privileges removes the usual safety net of “I did not click anything.” If a flaw like that were ever paired with a working exploit in the wild, careful behavior alone would not protect you. The patch would.

Also keep the count in proportion. More than 200 fixes sounds alarming, but a large monthly total is partly how Android works: one bulletin covers the operating system, the kernel, and several chip vendors at once. The number is a reason to install the update. It is not, by itself, proof your phone is under attack. Google also rolled out patches for 17 of these flaws early through Google Play system updates, so some pieces may already be fixed before your manufacturer ships the full patch.

What to actually do

First, check your patch level, not just whether an update is “available.” On most Android phones that is under Settings, then About phone, then Android version, where the Android security update date is listed. You want to see 2026-11-05 or later for the complete bulletin. A phone sitting at 2026-11-01 has the Framework and System fixes, including the most severe flaw — that is real protection — but it does not yet have the kernel and chipset fixes from the second part.

Second, install what your manufacturer offers, when it offers it. Pixel phones usually get Google’s fixes first, and other brands follow on their own schedules. If your phone says no update is available yet, that is a manufacturer timeline problem, not something you did wrong. Check again in a few days rather than sideloading software from a random site, which trades a patched risk for a much bigger one.

Third, run the other update too. Open the Google Play system update check in your security settings and install anything waiting there. As this month shows, some Android fixes travel that route, separately from the main system update, and it is easy to be current on one and behind on the other.

Finally, if your phone has stopped receiving security updates entirely, treat this bulletin as information about your next purchase. A phone that can no longer reach a current patch level carries every one of these flaws permanently. The patch level screen is the honest scoreboard — check yours today, update to 2026-11-05 when your maker ships it, and you have done the part that is actually in your control.

Sources: SecurityWeek, “Android’s November 2026 Updates Patch Over 200 Vulnerabilities” (November 3, 2026) — securityweek.com/androids-november-2026-updates-patch-over-200-vulnerabilities; CyberInsider, “Android November update fixes critical flaws and ‘SMS of Death’ bug” (November 3, 2026) — cyberinsider.com/android-november-2026-security-update-sms-of-death.

The safest moment in a WordPress site’s life is supposed to be the moment it updates. This week we learned that, for a few seconds, that moment was the dangerous one — and attackers figured it out within minutes.

What happened

On October 28, WordPress released version 7.1.4, a security release fixing 22 vulnerabilities, according to Wordfence. The most serious one has no account requirement at all: an unauthenticated race condition in the Core update process that can lead to remote code execution. Wordfence scores it 8.1 out of 10, High, and says it affects WordPress Core versions 4.7 through 7.1.3.

Here is the mechanism, in plain terms. When WordPress installs a full-package Core update, it unpacks the new files into a staging directory under wp-content/upgrade. That staged copy includes the WordPress installer, the staging path is predictable, and on many servers it is reachable from the web. If an attacker with no account on your site at all requests that installer at exactly the right moment, they can interact with the staged copy and work their way to running PHP code on your server.

The catch for the attacker is timing. Wordfence says that in normal lab environments the staging directory is available for only seconds, before WordPress cleans up the temporary files. Winning that race takes a full-package update containing the installer files, public web and PHP access to the staging tree, a predictable or discovered staging path, and enough time to finish before cleanup. That is a real list of conditions — and it did not slow anyone down.

Attackers did not wait

Wordfence deployed a firewall rule for this flaw on October 28 at 20:30 UTC, about three hours after the release was announced. The first attack matching that rule arrived nine minutes later. In the first 21 hours, Wordfence recorded more than 18,500 requests targeting staged setup-config.php installer paths. By the time The Hacker News reported the story on October 30, Wordfence said it had blocked 62,969 attacks targeting the vulnerability in 24 hours.

The behavior matches the bug. Two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours — exactly what you do when you are waiting for a seconds-long window to open. Other sources tested many staging-directory and version-name variations. Nobody wins this race by luck. They win it by asking, over and over, until a site happens to be mid-update.

How bad is it, honestly?

Serious, but keep it in proportion. The impact if an attacker wins is as bad as it gets — code running on your server, no login needed. The probability on any single update is low, because the window is seconds and the conditions have to line up. What pushes the risk up is repetition and automation: polling is free, sites update regularly, and every full-package update on an unpatched version opens the window again.

Also be precise about what the numbers mean. Those tens of thousands of blocked requests are attempts, not break-ins. The sources I read report active exploitation attempts; they do not report a confirmed compromise from this flaw. Treat a hit in your logs as a reason to look, not as proof you were breached.

One more wrinkle matters if you rely on Wordfence Free, as plenty of small sites do. Premium, Care, and Response customers got the new firewall rule on October 28. Free users get it on November 27, after the standard 30-day delay. Until then, the patch — not the firewall rule — is what protects a free site. Wordfence also notes that because this attack requests a PHP file directly, without loading WordPress first, sites using its firewall should confirm Extended Protection is enabled.

What to actually do

First, do not assume the auto-update landed — verify it. Go to Dashboard, then Updates, and confirm your site is running WordPress 7.1.4 or the corresponding patched release for your branch. The fix was backported through WordPress 4.7, so older branches have their own patched versions; WordPress 4.6 and earlier no longer receive security updates at all and need a real upgrade, not a patch. The fix itself randomizes the staging directory, adds an index guard, and stops staged configuration data from being promoted unsafely.

Second, patching closes the hole, but it does not answer whether someone got in before you patched. If your site sat unpatched, look for suspicious requests to PHP files under wp-content/upgrade, unfamiliar administrator accounts, and plugins or PHP files you did not put there. Then run a full security scan after updating.

Third, keep the boring rule that prevents the next one of these: leave automatic updates on for Core, plugins, and themes. I run several WordPress sites, and the lesson I take from a nine-minute gap between a firewall rule and the first attack is that there is no grace period anymore. The time between “patch released” and “someone is actively trying it” is now measured in minutes, and the only schedule that keeps up with that is the one that updates without waiting for me.

Update today, verify the version number with your own eyes, and check the upgrade folder in your logs. That is the whole job — and right now, it is genuinely enough.

Sources: Wordfence, “WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE; Exploitation Attempts Detected After Release” (October 29, 2026) — wordfence.com/blog/2026/10/wordpress-7-1-4-security-release-rce; The Hacker News, “WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours” (October 30, 2026) — thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.

Most security bugs live in an app. You patch the app, you move on. This one lives underneath every app on the box, and that is why I am spending my Sunday on it.

The bug is CVE-2026-98432, a use-after-free flaw in the Linux kernel’s IPv4 TCP handling — the code that runs when a server accepts a new connection, before any application sees a byte. The Linux kernel’s own CVE authority scores it 9.8 out of 10, Critical. On October 30, Red Hat raised its rating to Critical at 9.8 as well and published emergency bulletin RHSB-2026-016. When Red Hat moves a kernel bug to 9.8 and rushes out a bulletin, I pay attention.

What actually breaks

When a client opens a TCP connection, its first packet can carry IPv4 options. The kernel saves them, hands them from the half-open connection to the finished socket without copying them, and can free that memory while another processor is still reading it. That is a use-after-free. In the kernel it can mean leaked or corrupted memory, a crash — or, as Red Hat puts it, remote code execution.

Red Hat says a remote attacker needs no privileges and no user interaction, though precise timing is required, because this is a race. Anthropic, whose researcher Xinyang Ge reported the bug, showed why that caveat should not comfort anyone. In its October 27 write-up, Anthropic said its Claude model built a working proof of concept against a server with a multipath TCP (MPTCP) listener: about 48 minutes to leak a kernel pointer, then about five more minutes to run commands as root. A lost race only fails the handshake, so an attacker can try again.

Do not let the MPTCP detail shrink this. The Go Security Team warned on October 29 that the bug is not specific to MPTCP, and similar attacks may be possible without an MPTCP listener. Go matters because Go 1.24 enables MPTCP by default for listen sockets on Linux — so plenty of Go servers have exactly the listener shape the demonstration used, whether their owners chose it or not.

Who is affected, and the awkward part

The flaw goes back to Linux 4.4. Upstream fixed it in October — fixed stable releases are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, and 7.2.10, plus 7.3 in mainline. The fix is tiny: wait for readers to finish before freeing that memory.

Here is the awkward part. Almost nobody runs an upstream kernel — we run our distribution’s kernel, and status is split. As of checks published October 31 and November 1: Debian has fixed kernels out, Amazon Linux lists its families as fixed, and SUSE and Oracle Linux have fixes for parts of their lineups. AlmaLinux has patched kernels in testing, not production. And the two names most servers run — Ubuntu and Red Hat Enterprise Linux — had no fixed kernel yet. Ubuntu showed every release as vulnerable, with work in progress. Red Hat listed RHEL 8, 9, and 10, plus OpenShift, as affected, fixes expedited, none released.

Containers do not save you. Every container shares the host’s kernel, so rebuilding an image changes nothing. On Kubernetes, this is a node problem, not a pod problem.

How bad is it, honestly?

I am not calling this an active disaster, because the sources do not. As of November 1, the trackers I read found no confirmed in-the-wild exploitation, Anthropic has not published its exploit code, and the bug was not in CISA’s Known Exploited Vulnerabilities catalog in the feed checked October 31.

But a remotely reachable 9.8 in the handshake path, with a demonstrated path to root and the two biggest server distributions still waiting on packages, is exactly the window attackers like — the gap between public details and your distro’s kernel landing.

What I would do today

First, check what is running, not what is installed: uname -r on every Linux host, including container hosts and Kubernetes nodes. Compare it against your distribution’s tracker for this CVE — not the upstream numbers, because distro kernels backport fixes under their own versions.

Second, check for the demonstrated exposure: sudo ss -Mlnp lists MPTCP listeners. If something is listed, that host goes to the top of your patch list, and that listener should not sit open to the internet while you wait.

Third, if your distro has the fix, install it and reboot. A kernel update does nothing until the machine boots into it — a box that updated but never rebooted is still running the vulnerable kernel.

Fourth, if your distro has no fix yet, use the stopgap honestly. Red Hat’s bulletin publishes an nftables rule dropping incoming IPv4 TCP packets carrying IP options — headers longer than the standard 20 bytes. Normal TCP almost never carries IP options, so for most servers this costs nothing. Red Hat is clear: the rule reduces exposure but cannot fully prevent the vulnerability, can disrupt workloads that really use IP options, and does not replace a fixed kernel. Turning MPTCP off if you do not use it removes the setup the demonstration needed — a reduction, not a fix.

My rule is simple: patch the host, not the app. Check your kernels today, put the stopgap on boxes still waiting, and reboot into the real fix the day your distro ships it.

Sources: Atlas, “Linux’s October 2026 TCP Use-After-Free: CVE-2026-98432” — atlasum.net/blog/cve-2026-98432-linux-ipv4-tcp-uaf; BytesNation, “CVE-2026-98432: A Remote Root Bug in the Linux TCP Handshake” (updated November 1, 2026) — bytesnation.com/blog/cve-2026-98432-linux-tcp-handshake-use-after-free; NeoTeo, “Linux TCP flaw CVE-2026-98432: vendor updates” (November 1, 2026), reporting Red Hat’s CVE page and bulletin RHSB-2026-016, Anthropic’s October 27 account, and the Go Security Team’s October 29 guidance — neoteo.com/en/red-hat-rates-cve-2026-98432-critical-and-limits-its-filter.

On Friday, CISA added two more Ivanti Connect Secure flaws to its Known Exploited Vulnerabilities catalog. That catalog is the list of flaws CISA says are being exploited in the real world, not flaws that might matter someday. These two are the part of an attack chain a lot of people thought was already closed — and that is exactly why I am writing about them today.

The two new entries are CVE-2026-111357, scored 8.8, and CVE-2026-118527, scored 4.3. On their own, neither headline tells the whole story. The first is a missing authentication for a critical function flaw that, as The Hacker News describes it, could allow a local authenticated attacker to escalate their privileges. The second is a generation of predictable numbers or identifiers flaw that could allow a remote authenticated attacker to upload files with attacker-controlled content to a known location on disk.

Read those scores in isolation and you might rank the 4.3 near the bottom of your list. That would be a mistake — attackers did not use these flaws in isolation.

The chain is the problem

These bugs are part of an exploit chain first documented by Volexity earlier this month. Attackers weaponized them together with an authentication bypass flaw, CVE-2026-104935, scored 8.6, which CISA added to the catalog on October 13, 2026. In Volexity’s words, quoted by The Hacker News: “This exploit chain combined an authentication bypass, a remote code execution (RCE), and a privilege escalation vulnerability to achieve unauthenticated root-level code execution.”

Unauthenticated root-level code execution. No login, and then the highest level of control on the box. That is the sentence that matters.

The actor behind this is one Volexity tracks as UTA0576, described as previously undocumented. This was not the usual pattern of dropping a web shell and moving on. UTA0576 has been observed extracting credentials and limited Active Directory metadata, conducting host reconnaissance, and searching for administrator passwords and BitLocker recovery keys.

Think about where a VPN appliance sits. It is the front door remote workers use to get in. If someone takes root on that door and goes hunting for administrator passwords and BitLocker keys, they are not vandalizing a website. They are collecting the keys to the rest of the building.

If you patched in mid-October, patch again

This is the practical trap in this story. Ivanti fixed the front part of the chain in October. If you applied that fix and closed the ticket, your work looked done. It was not.

Ivanti said that when the exploitation details were published, it was still working on fixes for the local privilege escalation flaw used in the chain, and that it chose not to delay the CVE-2026-104935 fix it already had in QA while that work finished. I understand that call — ship the door lock you have rather than wait — but it leaves a follow-up job that is easy to miss.

Patches for both of the new flaws are now available. If you run Ivanti Connect Secure 25.1.1.2 or earlier, the fixed release is 25.1.1.3. If you run 22.8R2.5 or earlier, the fixed release is 22.8R2.6. The Hacker News notes that the latest release addresses all the vulnerabilities which were chained and exploited in the wild.

CISA’s deadlines tell you how urgent this is. Federal agencies must apply the fix for CVE-2026-111357 by November 2, 2026, and for CVE-2026-118527 by November 13, 2026. Those deadlines only legally bind those agencies. For the rest of us, November 2 is the date to copy anyway — Monday, not some time this quarter.

How bad is it, honestly?

If you do not run Ivanti Connect Secure, this one does not touch you directly — no reason to panic about your laptop or home router. If you do run it, or your employer or provider does, this is as serious as VPN flaws get: root without a login, on the device meant to control who gets in.

I am not going to inflate the individual scores. The 4.3 flaw is not critical by itself, and the 8.8 flaw, described as a local authenticated escalation, sounds contained by itself. Chains change the math. A bypass gets an attacker in, an upload or code execution flaw gives them a foothold, and an escalation flaw hands them root. Judge the chain, not just the pieces.

What I would do today

First, find out whether anyone in your organization runs Ivanti Connect Secure, and what version it is actually running — not what the change ticket says it should be. Second, upgrade to 25.1.1.3 or 22.8R2.6 for your branch, and verify the running version afterwards. Third, do not stop at patching if that appliance was exposed during October. The behavior Volexity observed is a reason to treat a possibly hit appliance as a credential problem too, and check what accounts and secrets that box could have seen. Fourth, if you are a user, not the admin, ask one simple question: have we applied the late-October Ivanti release, not just the mid-October one?

Patching once and assuming the story ended is a normal human habit. Attackers count on it. This chain got a second chapter, and the fix is out — finish the job.

Source: The Hacker News, October 31, 2026 — Attackers Chain Three Ivanti Connect Secure Flaws to Gain Unauthenticated Root Access, reporting CISA’s catalog additions, Volexity’s documentation, and Ivanti’s fixed releases.

On Thursday, CISA added a GitLab flaw to its Known Exploited Vulnerabilities catalog. That catalog is not a list of things that might be a problem someday. It is the list of flaws CISA says are being exploited in the real world. When something lands there, I stop treating it as routine patching and start treating it as urgent.

The flaw is CVE-2026-97229, and it carries the highest score there is: 10.0 out of 10. It affects self-managed GitLab Community Edition and Enterprise Edition. According to CISA and The Hacker News, it is an integer overflow in how GitLab handles a specially crafted regular expression in a CI/CD configuration, and it can let an unauthenticated user — no login, no account — execute arbitrary code on the GitLab server.

Let me put that in plain terms. GitLab is where a lot of teams keep their source code and run their build pipelines. If an attacker can run their own code on that server without logging in, they are not just knocking on the door. They are inside the building where the code, the build jobs, and often the secrets those jobs use all live. That is why a 10.0 here is not hype. The score matches what is actually at stake.

Who is affected

If you use GitLab.com, you can relax a little: GitLab says that service was already patched before disclosure, and GitLab Dedicated customers do not need to act. The work falls on people like me who run servers themselves — anyone with a self-managed GitLab instance.

GitLab fixed this on October 12 in versions 19.2.8, 19.3.5, and 19.4.2. The affected ranges are 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. If your instance is in one of those ranges, upgrade to the fixed release for your branch — or to the newest release on that branch — now, not at your next maintenance window. CISA has told federal civilian agencies to apply the fixes by November 1, 2026. That deadline only legally binds those agencies, but it tells the rest of us how seriously to take the timeline.

The Alpine Linux lesson: upgrading GitLab may not be enough

The most useful part of this story is what happened to Alpine Linux, and it is the part I want every self-hosting admin to read twice.

An attacker targeted Alpine’s own GitLab instance on October 20 and 21, sending crafted CI configurations that crashed its GitLab worker processes eight times. In four of those crashes, the exploit failed at the next step. Alpine’s team said it plainly: “The attack came close to working.” They found no evidence it succeeded, but they could not rule it out, so they treated the instance as compromised and rebuilt it from scratch. Their checks showed the aports repository, packages, and the October 21 releases were not tampered with. Follow-up attempts on October 25 and 26 were blocked.

Here is the catch they uncovered. GitLab’s fix is a patch to the Ruby that GitLab bundles inside its own packages and container images — the bug itself sits in Onigmo, the regular expression engine built into Ruby. Alpine’s image used a standard Ruby, so upgrading to GitLab 19.3.6 on October 22 did not close the hole. If you built GitLab from source, or your container image installs its own Ruby, upgrading GitLab alone leaves you exposed. Those installs also need Ruby updated to 3.3.13, 3.4.12, 4.0.9, or later. Ruby 3.2 will not get this fix, so a server on 3.2 needs a real Ruby upgrade, not just a patch.

That is a lesson that goes well beyond GitLab: a patch only fixes the copy of the code it actually touches. Know how your software was built before you assume an upgrade covered you.

What I would do today

First, check your GitLab version and how it was installed — official package, official image, or your own build with your own Ruby. Second, upgrade GitLab to a fixed release, and if there is a separate Ruby in the picture, upgrade that too, then verify the running versions, not just the installed ones. Third, look back at your logs around any worker crashes or strange CI configuration activity — repeated crashes are exactly what Alpine saw while someone was probing them. Fourth, if you find signs someone was testing this against you, do not just patch and move on. Alpine rebuilt from scratch because they could not rule out success. Copy that caution.

One more from the same CISA update: Cisco’s CVE-2026-76418, scored 8.6, lets an unauthenticated remote attacker reload Cisco Secure Firewall ASA and FTD devices running SSL VPN, causing a denial of service. Cisco says it saw active exploitation in October, fixes are out, and if you cannot patch right away, Bleeping Computer notes Cisco’s mitigation of disabling secondary authentication on the DefaultWEBVPNGroup tunnel group. If you run those firewalls with SSL VPN enabled, that is your second job today.

Patch the thing that is actually exploitable, verify the patch actually landed, and check whether anyone came knocking while you were exposed. That order matters.

Sources: The Hacker News on the CISA KEV addition (https://thehackernews.com/2026/10/cisa-adds-actively-exploited-gitlab-rce.html), The Hacker News on the Alpine Linux attack (https://thehackernews.com/2026/10/attacker-tried-to-exploit-alpine-linuxs.html), Rapid7’s analysis of CVE-2026-97229 (https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab/), and Bleeping Computer on the Cisco flaw (https://www.bleepingcomputer.com/news/security/cisco-warns-of-firewall-zero-day-exploited-to-crash-ssl-vpn-devices/).

The most effective hack I have seen did not involve code at all. It involved a polite voice, a plausible story, and a request that felt reasonable in the moment. Nobody broke in. Someone was let in, because the person on the other end sounded like they belonged there. That is social engineering, and it works because it targets people, not machines.

The risk in plain words is that an attacker can get passwords, codes, or access by asking for them, rather than by stealing them technically. They do not need to defeat your software if they can persuade you, or a colleague, to hand over what they need. This is why even well-protected systems can be undone by one convincing phone call.

The risk in plain words

Social engineering covers a range of tricks, but they share a pattern: a believable identity, a reason to act, and pressure to act now. A caller may claim to be from a bank, a software company, or a service you use, and say there is a problem with your account. A message may claim a package is held, a payment failed, or a colleague needs help urgently. The details vary, but the goal is the same: to get you to share a code, click a link, install something, or move money before you have time to think.

Pretexting is the formal name for inventing a scenario to justify the request. The attacker may already know a few true facts about you or your workplace, which makes the story feel real. They may be calm and professional, or they may sound worried on your behalf. Either way, the story is designed to make the unusual request seem like the normal next step.

How it actually works

Pressure and urgency are the tells. Legitimate organizations rarely demand that you act in the next few minutes or lose access, and they do not ask you to read out a one-time code, install remote access software at their direction, or move money to a safe account. Attackers use urgency because a rushed person checks less. They also use authority, because most of us are trained to cooperate with someone who sounds official, and sympathy, because a caller who sounds like they are trying to help is easier to trust.

Phone scams add another layer, because a phone number on a screen can be spoofed, and a voice can be confident and practiced. A caller may know your name, your employer, or a recent purchase, because that information is often public or was exposed in an earlier breach. Knowing a few facts does not prove someone is who they claim to be. It only proves they did some homework.

What to actually do about it

First, slow down on purpose. If a message or call creates urgency, treat that urgency itself as a warning sign. Hang up, close the message, and contact the organization through a channel you trust, such as the number on their official site or the app you already use. Do not use a number or link provided in the suspicious message itself, because that is the part the attacker controls.

Second, never share one-time codes, passwords, or remote access with someone who contacted you first, no matter how plausible they sound. A real support team will not ask you to read out a code that was sent to you, and a real bank will not ask you to move money to protect it. If someone asks for either, end the conversation. That rule is simple enough to apply under pressure, which is exactly when you need it.

Third, agree on verification habits with people who might be targeted through you, such as family members or coworkers. If someone asks for money, access, or a password change in an unusual way, check through a second channel you already trust, even if the request claims to be urgent. A short pause to verify is not rude. It is the whole defense.

Finally, remember that being fooled is not a sign of carelessness alone. These tricks are practiced, polished, and aimed at normal human instincts to be helpful and cooperative. The defense is not to become suspicious of everyone. It is to have a few firm rules, like never sharing codes and always verifying through a second channel, that hold even when the story sounds good. The hack that asks nicely only works if you answer before you check.

I used to think a data breach was a one-time event. A company would announce it, I would change my password for that site, and the story would be over. What I missed was the second life of that stolen data. Breach dumps do not die. They are copied, combined, sold, and reused for years, long after the original headlines have faded.

The risk in plain words is that a password you used years ago, on a site you barely remember, can still unlock accounts you use today — if you reused it. Credential stuffing is the name for trying stolen username and password pairs against many other services, automatically, at scale. It works because people reuse passwords, and because attackers know that.

The risk in plain words

Think about how many accounts you have created over the years: shopping sites, forums, apps you tried once, newsletters, games. Each one asked for an email address and a password, and many of us gave them the same few passwords, with small changes. If any one of those services is breached, the combination of that email address and that password becomes a key that can be tried everywhere else.

Email addresses make this worse, because most of us use the same address for almost everything. An attacker does not need to guess your username. They already have it from the breach. They only need to find one password that you reused, and then they can try that pair against email, banking, cloud storage, and social accounts, one after another, until something opens.

How it actually works

After a breach, stolen credentials are often collected into large lists. Those lists are combined with lists from other breaches, which makes them more powerful, because a password from one old site may match a newer account, and an email address may appear with several different passwords over time. Automated tools then try those pairs against login pages, often slowly enough or spread out enough to avoid simple blocks.

This is different from guessing. The attacker is not inventing passwords. They are using real passwords that real people actually chose, which is why even a fairly strong-looking password can fail if it was reused. If you used the same password on a forum in the past and on your email today, the forum breach is, in practical terms, an email breach too.

What to actually do about it

First, stop reusing passwords, starting with email and banking. Use a password manager to give every account a unique, long, random password. That way, a breach at one service gives an attacker a key that only fits that one lock. This is the single change that most directly defeats credential stuffing, because the attack depends on reuse.

Second, check whether your email address has appeared in known breaches, using a reputable breach-checking service or your password manager’s built-in check. If it has, do not panic, but do act: change the passwords for any accounts that shared the exposed password, starting with email, and turn on two-factor authentication where it is available. A second factor means a stolen password alone is usually not enough.

Third, watch for the signs that an old password is being tried: unexpected sign-in alerts, password reset messages you did not request, and accounts asking you to verify a change you did not make. Treat those as prompts to change the password for that account and to check whether you reused it anywhere else. Do not ignore them because you think the account is unimportant.

Finally, accept that you cannot delete a breach dump from the internet. You cannot call it back or ask every copy to be destroyed. What you can do is make it useless. Unique passwords, two-factor authentication, and a habit of changing exposed passwords quickly turn an old leak into a dead end. The dumps may never die, but they do not have to keep working.

I used to treat every coffee shop network as a trap. If I needed to check email on public Wi-Fi, I assumed someone was reading over my shoulder digitally, and I either avoided it completely or rushed through it with a VPN switched on. That fear was not entirely wrong, but it was out of date. The internet changed under it, and my habits needed to catch up.

The risk in plain words is not that public Wi-Fi is magic. It is that a network you do not control can be observed, manipulated, or faked. Someone on the same network, or running a fake hotspot with a familiar name, could try to see unprotected traffic or steer you to a fake page. The question is how much of your traffic is actually exposed in that way today, and what a VPN really changes.

The risk in plain words

Years ago, much web traffic was unencrypted, which meant that someone on the same network could read a surprising amount of it. That is no longer the normal case for major sites. Most reputable websites now use HTTPS, which encrypts the connection between your browser and the site. That encryption does not hide which site you visited from the network operator, but it does make the contents of the pages and the details you enter much harder for a bystander to read.

That change does not make public Wi-Fi harmless. A fake hotspot can still try to trick you, an old or badly configured site may not use encryption properly, and other services on your device may behave differently. There are also risks that have nothing to do with encryption, such as someone looking at your screen, or a device that automatically connects to a network name it has seen before. Public Wi-Fi is lower risk than it once was, not no risk.

How it actually works

A VPN creates an encrypted tunnel from your device to the VPN provider, and then your traffic goes out to the internet from there. On a public network, that tunnel hides the contents and destinations of your traffic from the local network operator and from other people on that network. In that narrow sense, it does help, especially if you are worried about the network itself.

What a VPN does not do is just as important. It does not make a bad site safe, it does not stop phishing, and it does not make you anonymous. The VPN provider can see your traffic in the same way the network operator could have, so you are shifting trust from one party to another, not removing trust entirely. A free VPN that is vague about how it makes money deserves skepticism, because running that service costs money, and your attention or data may be the product.

What to actually do about it

First, keep your device and browser updated, and look for HTTPS on sites where you sign in or enter sensitive information. If a browser warns you about a certificate or a connection, do not click through the warning on public Wi-Fi to get to an important account. That warning is doing exactly the job it is meant to do.

Second, be careful about which network you join. Ask staff for the correct network name if you are unsure, and turn off automatic connection to open networks where you can. Avoid doing banking or other sensitive work on a network you do not trust if you can wait, not because every public network is hostile, but because waiting costs little and removes a whole set of questions.

Third, use a VPN when it fits a real need, and choose one deliberately. A reputable, paid VPN from a provider with a clear privacy policy makes sense if you regularly work on public networks, if you need to protect traffic from a local network operator, or if your work requires it. Turn it on before you connect to sensitive services, and do not assume it replaces strong passwords, two-factor authentication, or careful checking of links.

Finally, keep the honest both-sides view in mind. HTTPS changed the math a lot, so public Wi-Fi is not the free-for-all it once was. A VPN can add a useful layer, but it is a layer, not a cloak. I still use public Wi-Fi when I need to, I still use a VPN in situations where I do not trust the network, and I do not let either choice replace the basics that protect me everywhere.