AI Weekly Malaysia

Beacon, a CRM provider serving 1,500+ charities, says an AWS access key likely exposed in public JavaScript build artifacts is the leading suspect in a July 27 breach. The attacker copied the entire customer database—including attachments—and probably downloaded it in readable form within 1 hour 27 minutes, despite data being encrypted at rest, because the compromised key allowed decryption. Beacon's logs cannot identify which specific records were exfiltrated.

Why: If you ship JavaScript bundles to browsers, scan your build artifacts for embedded cloud credentials before deployment—this incident shows that encryption at rest is meaningless when the access key that can decrypt it is sitting in a public JS file. Founders running SaaS on AWS should verify that IAM keys are never bundled into frontend assets and that CI/CD pipelines include secret-detection steps.

Tailscale traced a series of outages starting August 2025 to a 16-year-old bug in SQLite's write-ahead log checkpointing process. After a six-month investigation, SQLite maintainers had to build a new VFS activity logging tool (funded by Tailscale) just to reproduce the issue, which resisted all initial debugging attempts. Tailscale has used SQLite as its primary database since 2022, and the corruption first surfaced during their routine snapshot-to-S3 backup pipeline.

Why: If you ship SQLite in production with WAL mode and periodic snapshot backups, this postmortem is a direct warning that WAL checkpoint corruption can surface silently and be extremely hard to reproduce. Database learners and builders should read the Tailscale write-up before assuming SQLite's WAL is bulletproof in backup-heavy workloads, and consider whether their own backup pipeline could hit the same edge case now that the bug is documented.

Tailscale experienced 19 separate SQLite database corruption incidents over six months, traced to a 16-year-old WAL-reset bug deep in SQLite. Their architecture uses one SQLite database per shard with a single Go writer, and their backup pipeline snapshots the full DB file to S3 every few minutes—corruption was first detected when a downstream data pipeline reading those S3 backups reported an error.

Why: If you run SQLite in production and take file-level backups or snapshots (especially with WAL mode), you should run PRAGMA integrity_check against your backups routinely—Tailscale's corruption was invisible to the live writer and only surfaced from the backup consumer. Anyone shipping SQLite-backed services should review whether their backup method correctly handles WAL state.

A 16-year-old SQLite write-ahead log (WAL) checkpointing bug caused recurring database corruption in Tailscale's tailnet infrastructure starting August 2025, taking six months to diagnose. Tailscale funded SQLite maintainers to build a new virtual file system logging tool to reproduce the issue, which engineer Alex Chan described as resisting all initial debugging attempts including checks on POSIX locks, memory management, and thread safety.

Why: If you ship SQLite as a primary database under continuous backup snapshots, this postmortem is a concrete lesson in how deep storage-layer bugs can masquerade as application-level corruption for months. The debugging methodology—systematically ruling out POSIX lock, memory, and threading theories before isolating checkpointing—is worth studying before you hit a similar wall. The fact that SQLite maintainers themselves had to write new tooling to reproduce it should reset expectations about how 'reliable and well-known' doesn't mean 'bug-free' for critical infrastructure.

The UK's criminal records office (ACRO) was reprimanded by the ICO after attackers maintained persistent access to its Kentico CMS v12.0.0 for over seven months (Aug 2022–Mar 2023), potentially exposing data on ~11,000 people. The root cause was running an unpatched CMS from September 2019 to March 2023, compounded by a miscommunication where the managed service provider didn't learn patching was its responsibility until February 2020 and still didn't actively monitor for vulnerabilities.

Why: If you outsource infrastructure or CMS management to an MSP, get the patching responsibility in writing and verify it's actually happening—ACRO's breach was caused entirely by an unpatched CMS and unclear ownership. Founders running any CMS (WordPress, Kentico, Drupal) should check whether patching is explicitly assigned in their vendor contracts and whether someone is actually applying hotfixes, not just assuming the MSP handles it.

Voyager 2 engineers extended the spacecraft's mission by roughly two years by switching multiple power systems simultaneously rather than sequentially, preserving thermal heat that keeps propellant lines from freezing. The team relied on 50-year-old power documentation where margins as small as 0.2 watts mattered, and validated their thermal-power model with a brief live test on the spacecraft before committing.

Why: This is a compelling engineering postmortem about optimizing under extreme resource constraints, but it has no direct practical impact on what this audience builds, ships, or decides. The takeaway is conceptual: when facing a shutdown tradeoff between power and heat, simultaneous switching can preserve thermal margins that sequential switching loses — a useful mental model for anyone managing constrained edge or IoT systems, but not actionable for most builders here.