A lot of proxmox 7.0-7 and < 8.0.4 has been rooted today, it's needed to have port :8006 open, exploitation demo here: https://forum.proxmox.com/threads/proxmox-ve-7-is-vulnerable-to-some-type-of-0day-rce-non-auth.186078/post-867875

The Hunt.io research team found an open directory staging the full toolkit behind an intrusion into a Philippine nuclear research agency and a naval contractor. The ownCloud path is the interesting part technically.

CVE-2023-49105 lets you forge pre-signed WebDAV URLs when the signing secret is empty, which is the default state on a fresh install. Five custom Python scripts on the server implement this: the signing routine passes an empty bytes literal as the PBKDF2 salt, sets OC-Credential to the account being impersonated, and issues GET requests against /remote.php/dav/files/<account>/<path>, receiving files as that user with no credentials. Four scripts target one account each, the fifth adds PROPFIND enumeration with Depth: 1 to walk folders that were not pre-enumerated.

The naval contractor was hit separately via CVE-2024-28000 (LiteSpeed Cache) using a custom Go reimplementation of MT19937 with PHP mt_rand() parity, verified against 11 known seed/output pairs, plus an XML-RPC brute force with rockyou.txt. Both produced unauthorized access independently.

We also found a separate, possibly unrelated EtherHiding compromise on the same WordPress site. A HuntSQL query on the smart contract address returned 174 unique IPs hosting likely compromised pages with the same NoChain loader strings.

Full writeup with IOCs, the signing routine, and MITRE mapping: https://hunt.io/blog/chinese-speaking-operator-philippine-nuclear-naval-contractor

I finally found some time to organize my notes on secure boot, remote attestation, measured boot and in general embedded security.

This is not ground breaking zero-day research but I figured some of you might like a good story. Good here is obviously subjective but I felt like it came out quite readable.

This blog builds heavily on public research so as already stated at the end of article if you liked some particular section, show the respective person some love :)

P.S.: yes I know the image is AI generated please don’t give me shit for that

Three variations on subversive use of DNS by the Agent are documented in Hugging Face's technical writeup of the July 2026 security incident involving OpenAI models. In this article, I discuss what each of these three types of DNS workarounds achieve in practice, the constraints an actor might have faced to attempt a particular one, and additional benefits from choosing each.

An operator left their full working directory exposed on an open HTTP server. Hunt.io crawled it, 2,616 files, and rebuilt the campaign from the corpus.

• Three exploitation paths in parallel: an asyncio credential brute-forcer, a CVE-2021-33044/33045 auth-bypass chain, and P2P relay abuse reaching cameras by serial number
• The relay path never authenticates the connecting party, only the session, via a cloud-issued token obtainable with the fixed SDK credentials in every Dahua client
• Two CVE labels in the tooling don't hold up: CVE-2024-39943 is an unrelated Rejetto HFS flaw, and CVE-2025-31702 is a narrower post-auth case, not the unauthenticated relay abuse (that path is a separate non-CVE issue documented by ITRES)
• Full PTCP tunnel breakdown, including the Inverted STUN packet and the bind-to-127.0.0.1 technique

Neutral attribution throughout, the corpus shows how the operation was built and run, not who ran it.

Check the full breakdown, IOCs and mitigation strategies:
https://hunt.io/blog/operation-cameraswarm-dahua-cameras-compromised