{"id":79917,"date":"2026-08-21T13:29:37","date_gmt":"2026-08-21T13:29:37","guid":{"rendered":"https:\/\/owncloud.com\/?p=79917"},"modified":"2026-08-21T13:29:37","modified_gmt":"2026-08-21T13:29:37","slug":"what-black-hat-2026-proved-about-php-based-file-platforms","status":"publish","type":"post","link":"https:\/\/owncloud.com\/de\/blogs\/what-black-hat-2026-proved-about-php-based-file-platforms\/","title":{"rendered":"What Black Hat 2026 Proved About PHP-Based File Platforms"},"content":{"rendered":"

Most of the coverage out of Black Hat USA 2026 and DEF CON 34 (Las Vegas, August 1 to 6) focused on the AI keynotes. Fair enough, they were the headline story. But there’s a narrower talk in the schedule that matters more for anyone running a PHP-based file platform: „Burning Tears of PHP’s Memory Hardening“<\/strong><\/a>, presented by Frank Wu and xia0o0o0o with Zhiyun Qian credited as a contributor, in the Exploit Development & Vulnerability Discovery and Application Security: Offense tracks.<\/p>\n

Quick who’s who: Frank Wu is the founder of Nebula Security<\/a> (Y Combinator, S26 batch), a DEF CON finalist with r3kapig, and previously led DARPA’s AIxCC automated program repair effort. He appears to be the same Frank Wu who was a PhD student at UC Riverside’s security lab under Zhiyun Qian<\/a> (@pkqzy888<\/a>), which would explain Qian’s contributor credit on this talk. xia0o0o0o (xia0.sh<\/a>, GitHub<\/a>, @Nyaaaaa_ovo<\/a>) is a fellow r3kapig member with a background in iOS and XNU kernel research. Nebula Security itself posts as @nebusecurity<\/a> and publishes code under github.com\/NebuSec<\/a>. Per their own YC listing, part of their pitch is an AI agent doing vulnerability research alongside the human team, which is a nice detail given everything else this article is about.<\/p>\n

The reported result of the talk: it weakens the security of applications built on PHP considerably, with Nextcloud (github.com\/nextcloud\/server<\/a>) and WordPress (github.com\/WordPress<\/a>) named specifically.<\/p>\n

Why this lands differently for oCIS<\/h2>\n

Nextcloud Server runs on PHP. Nextcloud forked ownCloud Classic (still called ownCloud Server at the time) in 2016, and Nextcloud still runs on that same legacy LAMP stack today. So does ownCloud Classic, still maintained on PHP 8.3. ownCloud Infinite Scale (oCIS) doesn’t. It’s written in Go, ships as a single compiled binary (github.com\/owncloud\/ocis<\/a>), and by default runs with no external SQL database in the platform metadata path. There’s no PHP runtime in that stack for a memory-hardening bypass to reach in the first place.<\/p>\n

I want to be careful here, because it’s tempting to turn „different runtime“ into „therefore invulnerable,“ and that’s an overclaim that gets picked apart at the next conference. Being Go-native doesn’t mean oCIS has no exposure of any kind. It means one specific, newly demonstrated class of exposure (defeating PHP’s own memory hardening) simply doesn’t apply, because the component it targets isn’t there.<\/p>\n

The bigger argument Weston was making<\/h2>\n

David Weston, CVP of Agentic Security at Microsoft<\/a>, opened Black Hat with a keynote called „The End of Rare: Defending When Offense Is Cheap.“ (More from him at dwizzzle.io<\/a>, @dwizzzleMSFT<\/a>, or LinkedIn<\/a>.) His core claim: classical defense assumed scarcity, expensive zero-days and strong perimeters, and that assumption doesn’t hold anymore. Microsoft’s own numbers backed it up. Weston cited a ninefold increase in vulnerability volume compared to March, with the company’s Security Response Center now doubling its patched-vulnerability throughput roughly every six weeks. Microsoft’s internal scanning tool MDASH found more than 200 Linux kernel vulnerabilities in an internal Azure Linux distribution, then auto-generated 182 proofs of concept from them, many of them fully working exploits.<\/p>\n

Weston’s prescription wasn’t „detect harder.“ It was „build differently.“ Memory safety is the industry’s long-running example: roughly 70 percent of vulnerabilities across the industry have historically traced back to memory-unsafe code, a figure Microsoft, Google, and CISA have all cited independently. Google’s own Android security team backs that up with newer numbers: memory-safety vulnerabilities in Android’s codebase fell from 76 percent of all reported issues in 2019 to under 20 percent by 2025, tracking closely with Android’s shift toward writing new native code in Rust instead of C\/C++. Android now has roughly five million lines of Rust in its platform, and across all of it, exactly one memory-safety issue has turned up (a near-miss in an image parser, caught and patched before it ever shipped). That’s not „zero bugs ever,“ but it’s a vulnerability density Google says is orders of magnitude lower than its C\/C++ code.<\/p>\n

Rust got the shout-out, not Go, and I won’t pretend the keynote said otherwise. But the underlying logic (put the safety property into the language and the build, rather than into a hardening layer applied afterward) is exactly the argument for why ownCloud Infinite Scale was written in Go instead of PHP in the first place. Go isn’t Rust. It doesn’t eliminate every category of concurrency bug, and garbage collection brings its own tradeoffs. But it does remove the whole class of manual memory-management errors that PHP hardening exists to paper over, which happens to be precisely the layer Wu and xia0o0o0o showed how to get around.<\/p>\n

Detection is losing ground too<\/h2>\n

Weston’s second thread was about detection losing value as a defensive strategy, since the old „Pyramid of Pain“ logic only works if attackers reuse tools and infrastructure. Increasingly, they don’t. He pointed to a case where attackers used Claude to generate fresh command-and-control code per target, against a Mexican water utility, instead of reusing a toolkit. If malicious code is bespoke per target now, static detection signatures age out fast.<\/p>\n

That points the same direction as the PHP finding: the fight is moving upstream, into what the software is built from and how, not into what perimeter tooling catches after the fact. A database-free, single-binary, Go-native architecture is a bet on the „built differently“ side of that argument, not the detection side.<\/p>\n

Worth adding here: whether a memory-hardening bypass like this one applies to your deployment isn’t something you have to take anyone’s word for, either way. ownCloud Infinite Scale’s source is public under Apache 2.0, at github.com\/owncloud\/ocis<\/a>. Auditable code, auditable policy, auditable operations, in the same sense that lets you verify the database-free claim, lets you verify this one too.<\/p>\n

What this doesn’t mean<\/h2>\n

It doesn’t mean oCIS is immune, and it doesn’t mean PHP-based platforms are indefensible. Nextcloud and ownCloud Classic have their own hardening practices, and plenty of production deployments run them responsibly. What Black Hat 2026 actually demonstrated is narrower and more useful than a superlative: one specific memory-hardening layer, in one specific runtime, can be defeated by a small, well-resourced research team, and that layer is load-bearing for two named, widely deployed platforms. Whether that matters to you depends on your risk model, your deployment, and honestly, on what your own team decides to do with the finding.<\/p>\n

If you’re weighing file-collaboration platforms against this kind of research and want to go deeper into how Infinite Scale’s architecture actually works (the messagepack-based metadata layer, the single-binary service model, where OPA\/Rego policy fits in), that’s exactly the kind of technical conversation this project is built to support.<\/p>\n

\n

Reference: Lukas Grunwald, „DEF CON 34 und Black Hat 2026: KI \u00e4ndert die Regeln,“ iX 9\/2026, pp. 30-31. (https:\/\/www.heise.de\/select\/ix\/2026\/9\/2619708403739033188; Paywall)
\n<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

A Black Hat 2026 talk defeated PHP’s own memory hardening. Nextcloud and WordPress were named directly.
\noCIS doesn’t run PHP. It’s Go, single-binary, no external SQL in the metadata path. That doesn’t mean immune, it means this specific bypass has nothing to reach.<\/p>\n","protected":false},"author":50,"featured_media":79918,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","inline_featured_image":false,"footnotes":""},"categories":[43,41,337,509,344,339],"tags":[],"class_list":["post-79917","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-comment","category-foss","category-infinite-scale","category-opensource","category-owncloud"],"acf":[],"_links":{"self":[{"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/posts\/79917","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/users\/50"}],"replies":[{"embeddable":true,"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/comments?post=79917"}],"version-history":[{"count":2,"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/posts\/79917\/revisions"}],"predecessor-version":[{"id":79920,"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/posts\/79917\/revisions\/79920"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/media\/79918"}],"wp:attachment":[{"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/media?parent=79917"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/categories?post=79917"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/owncloud.com\/de\/wp-json\/wp\/v2\/tags?post=79917"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}