Microsoft's September 2026 Patch Tuesday is its largest ever, fixing a record 966 vulnerabilities, including 105 rated critical and two zero-days already being exploited in attacks. BleepingComputer reports: This Patch Tuesday addresses 105 "Critical" vulnerabilities, 81 of which are remote code execution, 20 are elevation of privileges, 2 are information disclosure, and 1 security feature bypass. The approximate number of bugs in each vulnerability category is listed below: - 438 Elevation of Privilege Vulnerabilities - 19 Security Feature Bypass Vulnerabilities - 258 Remote Code Execution Vulnerabilities - 173 Information Disclosure Vulnerabilities - 56 Denial of Service Vulnerabilities - 16 Spoofing Vulnerabilities Last month, Microsoft's Patch Tuesday updates fixed 570 security flaws, following 400 vulnerabilities patched in August.

Read more of this story at Slashdot.

De surpresa, Apple liberou há pouco o iOS 26.6.2 (compilação 23G90) e o iPadOS 26.6.2 (idem). O macOS Tahoe 26.6.2, vale lembrar, foi lançado no mês passado.

Os updates de hoje incluem apenas uma correção para o problema que impedia o download de uma atualização de software através de uma conexão celular, de acordo com as notas de liberação divulgadas pela Apple — sendo, portanto, recomendados a todos os usuários.

Como os sistemas 27 já estão batendo à porta, é muito improvável que esses updates introduzam qualquer novidade significativa além dessa correção. Caso algo surja, no entanto, comentaremos aqui no MacMagazine.

Em testes, o iOS/iPadOS 27 e o macOS Golden Gate 27 estão disponíveis tanto a partir de versões beta para desenvolvedores quanto de betas públicas. É provável que eles ganhem versões Release Candidate (RC) após o evento especial de amanhã.

One of our Macs kept filling up its SSD even though there isn’t supposed to be anything more stored on it. Photos is set to optimize its storage, and Messages is set to only keep messages for a year. It should be pretty much in a steady state, but we kept getting alerts from Mail that it couldn’t launch because there wasn’t enough free space. It’s an M4 MacBook Air used mostly for Web stuff, but somehow it felt as slow as the Intel one it had replaced.

I deleted unused apps and offloaded photos. Restarting sometimes helped, so I thought maybe it was an issue with Time Machine snapshots not being reclaimed promptly, which has been an issue before. But what data would even be changing so much to create large snapshots?

The problem kept getting worse, so I broke out OmniDiskSweeper. It didn’t find anything unusual, except it showed that the totals for the main folders added up to about 90 GB less than was reportedly used on SSD. Disk Utility showed that there were no snapshots taking up space. There must be real files but not ones that the app could see.

I relaunched OmniDiskSweeper using sudo, and it found a huge amount of stuff hidden in the root account: /private/var/root.

I had thought that wasn’t really used except when running Terminal from macOS Recovery. But apparently various daemons store all kinds of stuff there now. The /private/var/root/Library/Logs folder alone was using 74 GB, and there were also several multi-GB cache folders.

The logs were almost entirely from RTCReporting, and I’m not the only one to run into this.

I deleted the files using OmniDiskSweeper, but that didn’t help. It turns out that by default it moves files to the trash, and I guess since it was running under sudo this meant the invisible trash folder for the root account. It’s better to hold down the Option key to Delete Immediately.

After deleting the files and restarting the Mac, the free space looked right at first but then steadily dropped. Pretty soon there were again 5 GB of RTCReporting logs with the Mac just sitting there. I started using sudo du -h -d 2 /private/var/root/ to track how the sizes were changing. Within a day it was back up to 27 GB.

Activity Monitor showed that rtcreportingd and fileproviderd were each using almost 100% CPU constantly. I immediately suspected Dropbox because it had been working poorly on this Mac for a year or so. It wouldn’t keep files offline and constantly seemed to be syncing even when files weren’t changing. Sure enough, turning off Dropbox stopped the CPU use and the ballooning log files.

This was our last Mac still using Dropbox, so it seemed time to migrate it to iCloud Drive. The syncing problems ended up not being limited to keeping files offline. It couldn’t even reliably download most of them from the cloud to move them out of the Dropbox folder, instead reporting I/O errors for most files. And the files that I did move to the Documents folder never synced that deletion up to the cloud. I ended up just downloading the whole folder from the Web interface. iCloud Drive uploaded everything quickly and then settled into a state of no CPU use.

Previously:

• Sunsetting Maestral
• When Dropbox Spawns a Million Folders
• Tahoe Free Space Problems
• Fixing “Optimize Storage”
• Update on Cloud File Provider Extensions

Lily Hay Newman (via Ben Lovejoy):

As AI models gain advanced capabilities to find vulnerabilities in software, develop ways to exploit them, and even carry out autonomous hacking sprees, researchers offered a sobering new example on Tuesday, disclosing vulnerabilities in the video conferencing platform Zoom that could have been exploited to take over targets’ devices. Anyone on a call that involved screen sharing, whether participants or the host, would have been vulnerable to a silent attack that could be carried out with no indication and no interaction from the victim.

Researchers from the digital defense firm A Security say the bug was discovered in early June using publicly available AI models, and that it took fewer than 20 prompts to uncover the vulnerabilities and create a working attack. Zoom issued a security advisory on Tuesday, including details about fixes the company has already begun rolling out to address the flaws, which affected devices running all operating systems that Zoom supports—Windows, macOS, Linux, iOS, and Android.

[…]

The vulnerabilities were specifically in the protocol used to facilitate real-time annotation during screen sharing.

I don’t understand how it could take over an iOS device when Zoom’s iOS screen sharing feature only allows observation, not control.

Previously:

• macOS 26.6.1
• Zoom Security Improvements
• Every Zoom Security and Privacy Flaw So Far

Alex Chan (Hacker News):

Many of these outages were caused by a single bug, deep in SQLite. It took months of intense forensics to track it down.

[…]

This lack of reliable trigger conditions meant we couldn’t reproduce the bug synthetically. Instead, we had to rely on deploying passive, forensic telemetry in our live environment to catch the corruption red-handed. Gathering live diagnostics for a database issue is the last thing we wanted to do, but we had no choice.

[…]

As an additional complication, the corruption didn’t occur on a regular schedule. Sometimes incidents would be hours apart, other times weeks. This made it difficult to predict progress or plan further work, because we were never sure when we’d get our next diagnostic dump. We had a six-week period between October and December when there were no corruption incidents, before they returned as an unwelcome Christmas present.

[…]

In two incidents, our transaction logs failed to replay cleanly. Upon closer inspection, we discovered that data written and committed by one transaction was inexplicably invisible to later transactions. A write had vanished into thin air without raising an error.

SQLite:

The bug is likely present in all version of SQLite from 3.7.0 (2010-07-21) through 3.51.2 (2026-01-09). It is fixed in version 3.51.3 (2026-03-13) and later. Backports of the fix are available for some earlier releases: 3.44.6 and 3.50.7.

The bug only affects databases in WAL mode when there are two or more database connections open on the same file, in separate threads or processes, and when those two connections attempt to write or checkpoint at the same instant.

Alex Chan:

This investigation is a useful reminder: running boring technology in a non-standard way is a risk. The common paths and standard configurations are incredibly well-tested and reliable. Most people use SQLite in a standard configuration and never face this sort of issue. Everything we were doing was a public, documented, supported configuration—but by taking manual control of the checkpointing process and running at our own aggressive pace, we stepped off the well-trodden operational path.

Scott Perry:

I spent the last two years of my time working on SQLite trying to chase this bug down. It was so rare that I never got an internal report; my assessment of the number of customers affected was “about a county’s worth”, some of whom were generous enough to allow their local Genius Bar to send me backups of the affected databases. I spent so many hours in a hex editor staring at the wreckage.

Top three data corruption bug of my career for sure, and the other two weren’t bugs in SQLite.

A former Tailscale employee got in touch and shared that they were checkpointing these databases every 250ms. Multiplied across a fleet of servers that is a fantastic way to surface a super rare bug—they basically built our test rack as a product, but two orders of magnitude more effective (partially due to scale, but mostly because our rack also panics devices at random in order to test the filesystem, NAND controller, etc. and rebooting takes a while)

[…]

13/10 fantastic bug. proof that 100% test coverage is a good start, and that formal methods are needed for critical applications.

Carl Sverre (Hacker News):

I whipped out my phone, and asked Claude to get to work. I had it get SQL 3.51.2 – still buggy – set up in Antithesis, and then instrument the code with a bunch of Antithesis assertions. You can see the instrumented version here.

Then I asked it to write a simple workload which exercised the WAL insert and checkpoint code. Notably, this is a completely generic workload. It just runs writes and checkpoints concurrently – things you’d expect to actually happen in production, all the time. The assertions are also generic to the bug, they’re all standard assertions you’d add to any database, things like “no lost committed writes” and “database is not corrupt” (called integrity check in sqlite).

On my first run, Antithesis caught the bug in 15 mins. Here’s the report.

Of course, it helps that he knew to look in the checkpoint code, but you could imagine using tools like this to quickly investigate hypotheses when you don’t already know the answer.