News

Emergency patches out now for those managing the millions of domains assumed to be affected

Emergency patches are available for a critical vulnerability in cPanel and WHM that allows attackers to bypass authentication and gain root access to servers managed using it.…

Investigation finds no single cause for soldiers falling ill, just bad bolts, cold air, and apparently the soldiers themselves

Britain's notorious Ajax armored vehicles are being accepted back from the manufacturer after investigations found no single cause for the symptoms plaguing crews, meaning soldiers will need to grin and bear it.…

PWNED Welcome, once again, to PWNED, the weekly column where we recount the adventures of IT explorers who found their own pile of quicksand and then jumped right into it. This week's story involves keeping sensitive information in a very vulnerable place and then not protecting it adequately. The tale comes to us courtesy of Stanislav Kazanov, head of strategic practices at Innowise, a software development firm. A few years ago Kazanov and his group were hired to perform compliance and data architecture audits on a fintech startup where execs had invested more than $1 million to develop a "military grade" security system complete with biometric MFA, endpoint detection, and a ton of physical security. During the audit, Kazanov logged onto the company's SharePoint site and found a folder called "DevOps_Handoff" on the company-wide intranet that any employee could access. Within that folder was a spreadsheet with the very obscure and deceptive filename Prod_DB_Root_Creds_DO_NOT_SHARE.xlsx. Clearly, this naming convention would throw off any would-be hackers. On the bright side, the Excel file was password-protected. So, at least there's that, but was there really that much protection? When Kazanov asked the lead engineer for the password, he was so embarrassed that he looked at his feet and mumbled the answer: "It's the [company name] + [year]." We don't know the actual name of the company, but let's just say it was Contoso. The password would therefore be contoso2026. That's not exactly "admin123" but it's close enough to guess. The lead engineer explained to Kazanov the reason for the file's existence. Apparently, the internal DevOps team and an external DBA team had a disagreement about which enterprise-grade password manager to use. To "temporarily" solve this disagreement, they dumped the root DB credentials and master AWS IAM keys into this spreadsheet, which had existed for a whopping eight months at the time our hero found it. Our story ends here. We assume this problem was resolved after Kazanov's intervention and before tragedy struck. However, it shows that disagreements over how to secure resources can lead to dangerous compromises. In this case, the internal DevOps team should have had the final say over what password manager the contractors and they would use. At no point should they have allowed this conflict to result in putting the secrets into a spreadsheet, even if the spreadsheet had strong password protection. The most basic principle of cybersecurity is to give individual access and credentials to only those who really need it. But here the file was on an intranet that was accessible to all employees and even contractors like Kazanov. Since this was a fintech firm, the data involved could have related to millions or even billions of dollars of people's money. This is a serious situation and anyone who is this sloppy with security doesn't deserve to handle a dime in assets or transactions. Have a story about someone leaving a gaping hole in their network? Share it with us at pwned@sitpub.com. Anonymity available upon request. ®

Great idea, guys. Let's keep all of the data in an Excel file with weak password protection

PWNED  Welcome, once again, to PWNED, the weekly column where we recount the adventures of IT explorers who found their own pile of quicksand and then jumped right into it. This week's story involves keeping sensitive information in a very vulnerable place and then not protecting it adequately.…

Developers of major Linux distributions have begun shipping patches to address a local privilege escalation (LPE) vulnerability arising from a logic flaw. The newly disclosed LPE, dubbed Copy Fail (CVE-2026-31431), comes from a vulnerability in the Linux kernel's authencesn cryptographic template. "An unprivileged local user can write four controlled bytes into the page cache of any readable file on a Linux system, and use that to gain root," the writeup from security biz Theori explains. The kernel reads the page cache when it loads a binary, so modifying the cached copy amounts to altering the binary for the purpose of program execution. But doing so doesn't trigger any defenses focused on file system events like inotify. The proof of concept exploit is a 10-line, 732-byte Python script capable of editing a setuid binary to gain root on almost all Linux distributions released since 2017. Copy Fail is similar to other LPE bugs such as Dirty Cow and Dirty Pipe, but its finders claim it doesn't require winning a race condition and it's more broadly applicable. It's not remotely exploitable on its own – hence LPE – but if chained with a web RCE, malicious CI runner, or SSH compromise, it could be relevant to an external attacker. The bug is of most immediate concern to those using multi-tenant Linux systems, shared-kernel containers, or CI runners that execute untrusted code. According to Theori, the vulnerability also represents a potential container escape primitive that could affect Kubernetes nodes, because the page cache is shared across the host. Linux distros Debian, Ubuntu, and SUSE have issued patches for the problem, as have overseers of other distros. Red Hat initially said it was going to defer the fix but later changed its guidance to indicate it will go along with other distros and patch promptly. The CVE has been rated High severity, 7.8 out of 10. Theori researcher Taeyang Lee identified the vulnerability, with the help of the company's AI security scanning software, Xint Code. The number of bug reports has surged in recent months, helped by AI-powered flaw-finders. Microsoft just reported the second largest number of patches ever. Dustin Childs, head of threat awareness for Trend Micro's Zero Day Initiative, expects this is due to security teams using AI to hunt bugs. "There are many things we could speculate on to justify the size, but if Microsoft is like the other programs out there (including ours), they are likely seeing a rise in submissions found by AI tools," he wrote earlier this month. AI-assisted vulnerability research recently prompted the Internet Bug Bounty (IBB) program to suspend awards until it can understand how to manage the growing volume of reports. ®

Patches land for authencesn flaw enabling local privilege escalation

Developers of major Linux distributions have begun shipping patches to address a local privilege escalation (LPE) vulnerability arising from a logic flaw.…