Blog

  • Apple Patched This Flaw in 2024. Attackers Are Using It Now.

    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.

  • When You Delete a File, Where Does It Actually Go?

    Every week I delete files like I am cleaning house — old downloads, screenshots I do not need, installers I will never run again. I click delete, the name disappears, and it feels finished. It usually is not, at least not right away. Deleting a file and erasing the data inside it are two different jobs, and most computers only do the first one. Once I understood that, a lot I had seen over the years — files “recovered” from a drive that was supposed to be empty — stopped being mysterious.

    A File Is Two Things, Not One

    A file on a drive is really two separate things. The first is the data itself: the actual bytes, sitting in blocks on the disk. The second is a directory entry — a record in the filesystem that says a file with this name exists, it starts at this block, and it runs this long.

    Think of it like a book in a library. The data is the book on the shelf. The directory entry is the card in the catalog. Reading a file means checking the catalog, walking to the right shelf, and reading what is there. Without the card, I would have no way to know the book exists — but the book has not moved.

    What Delete Actually Does

    When I delete a file for real — not send it to the trash, but delete it past that point — the filesystem mostly does the cheap, fast version of the job. It removes or marks invalid that file’s directory entry, and it marks the blocks the file was using as free for future use.

    It does not, in most cases, go out and scrub those blocks clean. Scrubbing would take time and wear on the drive, and most of the time nobody needs it. The data sits where it was, untouched, until something else needs that space and overwrites it. The file is gone in every way that matters for normal use. It is not gone in the physical sense.

    The Trash Is Just a Waiting Room

    The Recycle Bin on Windows and the Trash on a Mac or a Linux desktop are an even softer version of deleting. Sending a file there does not free any space at all. The file is simply renamed and re-cataloged into a holding folder, with a note about where it came from so it can be put back. That is why restoring from the trash is instant: nothing ever left. Emptying the trash is the step that actually reclaims the space. Until I empty it, I have not deleted anything — I have just tidied it into a different pile.

    Why Recovery Sometimes Works — and Sometimes Does Not

    This one fact explains file recovery. If the directory entry is gone but the blocks have not been reused yet, recovery software can scan the drive, recognize the shape of leftover data, and rebuild a file out of it. The sooner I stop writing new data to that drive, the better the odds, because every new save may land on top of the old blocks. Once they are overwritten, that copy is gone for ordinary purposes — no program brings back data that has physically been replaced. Recovery is not magic; it is a race between noticing the loss and the drive reusing the space.

    SSDs Changed the Rules

    Modern solid-state drives add a twist. Because of how flash memory wears, an SSD spreads writes around on purpose, a process called wear leveling. That means asking an SSD to overwrite one specific file’s blocks does not guarantee the old blocks get touched at all.

    SSDs answer this with a command called TRIM. When the operating system deletes a file, it can tell the drive which blocks are truly no longer needed, and the drive clears them in the background on its own schedule. So on a modern SSD with TRIM working, a deleted file usually becomes unrecoverable much sooner than on an old spinning disk — but “sooner” is on the drive’s timetable, not mine, and I cannot point to the exact moment.

    The Copies I Forget About

    The last wrinkle is that deleting my copy often does not delete every copy. A photo I delete from my phone may still sit in a cloud backup, a synced folder, an old drive image, or the trash folder of the service I uploaded it to — each with its own delete button and waiting period. None of that is sinister; backups exist so one delete cannot ruin me. But a real cleanup has to follow the copies, not just the file in front of me.

    The Practical Takeaway

    Here is how I handle it. For ordinary files, delete plus emptying the trash is enough. For a drive I am selling or giving away, I use the built-in full reset or secure erase the maker provides, because that clears the whole device, not just its catalog. And for anything truly sensitive, the strongest move comes long before deleting: keep the drive encrypted from the start. Encrypted data left behind is just noise without the key.

    Delete was never an eraser. It is a card pulled from a catalog. Once I treated it that way, I got calmer about files I recover and more careful about ones I hand to somebody else.

  • Rails Just Patched a 9.8 in File Uploads — Update Before the Weekend

    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.

  • No Boss, No Time Clock: The Hard Part Is Still Showing Up

    I have spent a lot of my working life on somebody else’s schedule. Shift work in manufacturing, nights as a hotel night auditor, days that started when a manager said they started and ended when the next person walked in. You can complain about a schedule like that, and I did, but it has one quiet advantage: you never have to decide when to start. The clock decides for you.

    A lot of the work I do now does not work that way. If I am fixing a website, working on a computer problem, writing, or studying, there is no time clock and no supervisor standing in the doorway. Nobody knows if I start at seven or at noon. Nobody knows if I quit early, either. That freedom is real, and I would not trade it back lightly. It is also the hardest part of the job.

    The Freedom Is Real

    Let me give the freedom its due first. When work does not have to happen at a fixed place at a fixed hour, you can fit it around real life. A family obligation in the middle of the day does not require asking permission. A trip does not automatically mean the work stops, as long as it is work a screen can carry. If I think clearest early, I can start early. If a problem needs an uninterrupted stretch, I can take that stretch at night when the house is quiet.

    That flexibility is not a small thing. For a lot of people, especially outside big cities, the choice is not between a flexible job and a rigid one with better pay. It is between work they can shape around their lives and work that does not fit their lives at all. Flexibility is often the reason the work is possible in the first place.

    The Drift Is Real Too

    Here is the other side, stated plainly: nobody notices when you drift. Skip an hour and it turns into a morning. Put off the hard task and there is always an easy one — messages to check, news to read, a small fix that feels productive without actually moving anything forward. At a job with a boss, a slow day still puts you at your post. Working for yourself, a slow day can produce almost nothing, and there is no one to call it out but you.

    I think that is why so much advice about working on your own sounds like advice about discipline, when the real problem is simpler. A job used to supply the structure from the outside — a start time, a list handed down, a person expecting a result by a certain hour. Take that away and you have to supply the structure yourself, on purpose, every day. If you do not, the day supplies its own structure, and it is usually called distraction.

    The Opposite Trap

    There is a trap on the other side, and I have fallen into it as well: never clocking out. When the work lives on the same phone and the same laptop you use for everything else, it follows you to the kitchen table and into the evening. You can always do one more thing. Some days that extra push is exactly what a job needs. Done every day, it stops being diligence and starts being a slow leak. You end up tired without being able to point to what the tiredness bought.

    A time clock, for all its faults, also told you when you were done. Without one, you have to decide what done means for the day — and then honor it, the same way you honor a start time.

    What Actually Works for Me

    I keep it plain, because complicated systems are the first thing I abandon. The night before, I write down what tomorrow needs to produce — not a wish list, just the few things that would make the day count. In the morning I give myself a start time and keep it the way I would keep somebody else’s shift. Then I finish one visible thing first, before messages and browsing get a vote. A finished thing, even a small one, changes the feel of the whole day.

    And I set a stopping point. Not a vague one — a time, or a clear last task. When I reach it, I close the work down and let the rest of the day be the rest of the day. Some days I miss on all of this. The list helps anyway, because a missed plan at least shows me what slipped, instead of the day just dissolving.

    My practical takeaway is this: if nobody is setting your schedule, set a small one yourself — a start time, one thing that must get finished, and a time to stop — and treat all three like you promised them to somebody else. Freedom at work is not the absence of a schedule. It is a schedule you chose, kept by the only person who can keep it for you.

  • Android’s November Update Patches More Than 200 Flaws — Check Your Patch Level

    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.

  • Election Day 2026: The Brakes, the Bill, and Whether Congress Still Does Its Job

    Today is Election Day, and I do not mean that as a slogan. Polls are open, and by tonight we will start learning who runs Congress for the next two years. All 435 seats in the House are on the ballot, along with 35 seats in the Senate. Going in, Republicans hold the White House and narrow majorities in both chambers — 53 to 47 in the Senate and a House margin just as thin. Democrats need a net gain of four seats in the Senate to take that chamber, and a handful in the House. That is the math, laid out in Reuters’ reporting on today’s vote. Everything else is argument about what that math should mean.

    What Voters Say This Is About

    Start with what people told pollsters, because it cuts across party lines. In a Pew Research Center survey from late September into early October, 84 percent of registered voters said the economy is very important to their vote — the top item for Republican and Democratic voters alike. Health care and immigration followed, and a separate AP-NORC poll put the cost of living right beside the economy at the top. The Close Up Foundation’s breakdown of those surveys shows agreement on the problem even where there is no agreement on the fix. Groceries, gas, rent, and a doctor’s bill are not partisan experiences.

    The Strongest Case for Changing Control

    The Democratic case, in its strongest form, is a referendum case. A midterm is the one scheduled chance to grade a president’s first two years, and history is against his party — it has lost ground in all but two midterms since World War II. Democrats argue the grade should be low: that promises to bring costs down have not been kept, that tariffs and the war with Iran pushed fuel and household prices up instead of down, and that the big tax law paired extended cuts with deep reductions in Medicaid and other health programs. On that telling, divided government is not gridlock for its own sake. It is a brake — a House or Senate that can investigate, refuse, and force a president to negotiate instead of governing around Congress. If you believe the current direction is the problem, handing the other party at least one chamber is the most direct tool the Constitution gives you, and today is the day it is available.

    The Strongest Case for Keeping Control

    The Republican case, in its strongest form, starts by rejecting the referendum frame. Republicans argue they were elected to do specific things — extend the tax cuts, tighten border enforcement, and deport people here illegally — and that by their own measures they are doing them, with removals running at a high pace this year. They argue the cost pressure voters feel is driven heavily by a war and by energy markets no Congress controls in a single session, and that switching control now would not lower a grocery bill; it would produce two years of investigations, blocked appointments, and messaging bills neither side expects to become law. They also argue, not without a point, that opposition is not an affordability plan: if the other party wants the gavel, it should have to name what it would do about prices beyond stopping the president. If you believe the current agenda is broadly right and just needs time, keeping a working majority is how a voter says so.

    The Case Nobody Is Campaigning On

    There is a third argument I keep coming back to, and almost nobody on a ballot is making it. A commentary published November 1, summarized here, argues that Congress itself may be the biggest loser no matter who wins, because over roughly two decades it has handed its own powers away — letting presidents govern by executive order, fight wars, and set tariffs the Constitution assigned to the legislature. I find that hard to argue with. A Congress that mostly performs for cameras while the executive does the governing has failed at its job under either party’s management, and a veto override still takes two-thirds of both chambers, so a bare majority alone does not fix that.

    Do not forget the rest of today’s ballot, either. Voters in 39 states are deciding more than 140 ballot measures — voter ID, campaign finance, guns, marijuana, and more — as USA Today’s voter guide details. Some of those will change daily life faster than anything Congress does this year.

    Where I Land

    I wrote last month that a building stands best when it is not being pushed hard from one side, and I still believe that. One-party control removes the brakes, and brakes are not the enemy of getting somewhere — they are what let you go around a corner without leaving the road. So I am not afraid of divided government, and I do not buy that every check on a president is obstruction.

    But my bigger hope is simpler than a party result. I want whichever Congress shows up in January to act like the first branch again: write the spending bills, own the tariff and war decisions, and do the unglamorous work in the open instead of outsourcing it to executive orders and courts. Vote today if you have not. Then hold the winners — yours and theirs — to that job description.

  • WordPress Was Vulnerable While It Was Updating Itself — Update to 7.1.4

    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.

  • One Line in robots.txt to Say No to AI Training — Finally

    I spend a lot of my working life inside other people’s websites, and lately inside my own. So a small piece of news from the end of last week caught my eye, because it is about who gets to decide what happens to the words and pictures on a site after a crawler comes to visit.

    What Happened

    On October 30, Google, Microsoft, OpenAI, and Anthropic said they will back one shared instruction in a site’s robots.txt file for opting out of AI training. The token is called __usage_ai-training. I put that token in a robots.txt group with a Disallow rule, and every participating company is supposed to read it the same way: do not use this site to train your generative models. The proposal was written up as an Internet Draft by Kevin Kelley of Anthropic and submitted to the AI Preferences working group at the IETF, the body that handles internet standards. Reporting on the announcements is collected in this rundown of the new standard, which also notes the important limits below.

    Until now, I have had to do this one company at a time — one entry for GPTBot, another for Google-Extended, another for ClaudeBot, and so on — and then keep that list current as crawlers are renamed, split, or replaced. One line that names a purpose instead of a bot is the whole idea.

    The Case For It

    First, it lowers the bar to almost nothing. A small site owner with no developer and no legal team can copy one block into a text file and be done. The old list approach worked fine for big publishers; for the rest of us it was homework that never stayed finished.

    Second, a purpose-based rule survives change. Bots get renamed. Companies launch new crawlers. A rule that says “not for training” does not care what the crawler is called this year, and that is simply better design than chasing names.

    Third, the companies agreeing are the ones that matter most to most publishers, and they agreed on the same token instead of shipping four competing dialects. One syntax, in the one file site owners already know, is a real deliverable — and a clear, dated refusal on record is also useful evidence if a publisher ever ends up in a licensing argument.

    The Case Against It

    Now the other side, because there is one. To start with, it is not in force yet, and the timelines do not line up. Anthropic says it has begun implementing it. OpenAI talks about the coming months. Microsoft and Google point to 2027. Meta has expressed support with no commitment at all. An announcement is not an enforcement date, and in the gap a publisher who only adds the new line and deletes the old per-bot rules has actually weakened their position — so the old rules need to stay until each company confirms it is honoring the new one.

    It is also still just robots.txt, which has always been advisory. Nothing technically stops a crawler from ignoring it. It works because the big players have reputations to protect, and it does nothing at all about smaller scrapers with no reputation to lose, or about copies of a site already sitting in somebody else’s dataset.

    And it does not undo anything. It governs future crawls. It does not remove a site from models already trained, and it says nothing about paying for material already used. There is also a quiet split hiding in the details: Google plans to read the shared token as covering grounding — a model pulling live pages to build an answer — as well as training, while Microsoft treats grounding separately. So the same one line can mean slightly different things depending on who is reading it, which is exactly the kind of confusion a shared standard was supposed to end. Finally, note that a wildcard block does not trigger it: I have to name the token explicitly.

    Where I Land

    I am for it, with my eyes open. I will add the line to the sites I run, keep every existing per-bot rule in place beside it, and write down the date I added it. That costs me five minutes and states, in the clearest common language available, what I do and do not consent to.

    But I am not going to pretend a text file is a fence. It is a sign on the fence — one the biggest companies in AI have now publicly agreed to read the same way. That agreement is worth having, it was overdue, and it makes the next conversation, about what happens when the sign is ignored, a much cleaner one to have.

  • A 9.8 in the Linux Kernel — and Ubuntu and RHEL Don’t Have the Fix Yet

    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.

  • How DNS Turns a Name Into an Address

    Every time I type a website name into a browser and a page loads, a lookup happened first that I never saw. The name I typed — something readable, meant for a person — had to be turned into a number the network can actually route to. That turning is the job of DNS, the Domain Name System. I work with it every time I move a site or set up email, and most mysterious website problems turn out to be DNS doing exactly what it was told. Here is how it works, in plain words.

    Names Are for People, Numbers Are for Machines

    Computers reach each other using IP addresses — numerical addresses that identify a particular server on the network, either as numbers separated by dots or, in the newer and longer form, as numbers and letters separated by colons. Either way, nobody wants to memorize one for every site they visit.

    So we use names instead. DNS is the directory that connects the two: give it a name, and it answers with the address. It is often compared to a phone book, with one difference — there is no single book. The directory is spread across millions of servers, each responsible for its own small piece.

    Step One: Check What Is Already Known

    When I ask for a site, my computer does not start by searching the whole internet. It checks memory first. My browser keeps a short-term cache of names it has looked up recently, and the operating system keeps one too. If the answer is already there and has not expired, that is the end of the lookup.

    If nothing is cached locally, the question goes to a recursive resolver — usually a server run by my internet provider, or a public resolver I have chosen on purpose. The resolver’s job is to track down the answer on my behalf and hand it back.

    Step Two: Asking Down the Chain

    A domain name reads in layers, from the most specific part on the left to the most general on the right. The resolver follows those layers from the top down, asking servers that each know one level.

    First, it asks a root server who handles the ending — the top-level domain, such as .com or .dev. The root does not know my site’s address, only who handles that ending.

    Next, it asks one of those servers which servers are authoritative for that exact domain — again, just a referral one level closer.

    Finally, it asks the authoritative nameserver, which holds the domain’s actual records and is usually run by the registrar or hosting company. That server gives the real answer. The resolver returns it, my browser connects, and only then does the page load. Nobody holds the whole directory, and nobody needs to.

    The Records Themselves

    An authoritative nameserver does not hold one answer per domain. It holds a set of records, each answering a different kind of question.

    An A record points a name to an IPv4 address, and an AAAA record points it to an IPv6 address. These are the records a browser needs.

    A CNAME record points one name at another name instead of at an address — useful when a subdomain should follow wherever the main name goes.

    An MX record says where email for the domain should be delivered — a separate answer from the website’s address, which is why a site can be hosted in one place and its email handled somewhere else entirely.

    A TXT record holds plain text attached to the domain, commonly used to prove ownership to a service, or to publish rules helping other mail servers judge whether email claiming to come from that domain is legitimate.

    Why Changes Take Time: TTL

    Every record carries a TTL — a time to live — telling resolvers how long they may cache that answer before asking again. When I move a website to a new host and update its A record, the change takes effect at the authoritative server immediately. But every resolver and computer that cached the old answer keeps using it until its copy expires.

    That delay is usually described as the change “propagating,” but nothing is traveling. Old copies are simply aging out, on their own clocks. It is also why a site can load from the new host on my phone and the old host on my laptop at the same moment — their caches expire at different times. The fix is usually not another change; it is waiting for caches I cannot see to let go.

    The Practical Part

    Here is my takeaway. When a website or an inbox breaks after a move, I check DNS before anything else, because DNS is where a correct server gets sent no visitors, and where email quietly goes to the wrong place while the website looks fine. The website record and the email record are separate answers; fixing one says nothing about the other. And when a move is coming, I lower the TTL ahead of time, so the old answer expires quickly on moving day.

    DNS is invisible when it works. But it is the first system every visit and every email passes through — and once I understood it is just a chain of referrals ending at one server that actually knows, it stopped being magic and started being a checklist.