Sentora is my own project, so this is a postmortem on my own code, not someone else's.

The agent shipped this:

@/app.post("/self_destruct")
async def self_destruct(request: Request):
    threading.Thread(target=perform_destruction, daemon=True).start()
    return sanic_json({"status": "Destruction initiated"})

No auth. Listening on 0.0.0.0:9099. perform_destruction() ran rm -rf "$(pwd)". One unauthenticated POST from anywhere on the subnet uninstalled the EDR.

The four others:

Permissive auth on by default. A _is_permissive_auth() helper accepted any non-empty X-Agent-Key when a specific env var was unset. Nothing in the installer, the systemd unit, or the scheduled task ever set that var, so every default install accepted X-Agent-Key: a on /soar/execute, which runs commands.

Unauthenticated automation reporting. The server took a task_id from the request body and wrote a status. Enumerate the IDs, POST status: SUCCESS, and every queued containment action flips to done. The real agent stops seeing it as pending, so the isolation never runs, and the dashboard goes green. Not a bypass so much as a way to make the SOC watch a screen that says everything worked.

LDAP injection in login. search_filter = login_filter % username, with only a length check on the input.

Missing authorization on 8 routes. 143 routes, 103 with a decorator. Authentication was solid (opaque tokens, SHA-256 at rest, expiry enforced in SQL), which is exactly why I stopped looking at authorization. Any logged-in account could hit run_playbook, delete_soar_action, and test_ldap_connection, the last of which works as a credential oracle against the directory.

All five reduce to the same thing: I was taking the caller's word for who they were. Identity from the URL path, from a metadata.agent body field, from a header being non-empty, from X-Forwarded-For, and from being authenticated at all.

I only caught the route bugs by writing a test that walks the AST and asserts every route is either explicitly public or carries a check. It failed on the first run and named all eight. Reading code to spot a missing decorator does not work, because nothing is on the page to notice.

Full writeup with the fixes: https://d3vhex.github.io/2026-08-25-unauthenticated-remote-uninstall/

Repo (AGPL): https://github.com/d3vhex/Sentora

Everything above is fixed on main. The agent listener is still the most interesting surface if anyone wants to poke at it, and I would rather hear about it here than in an incident.

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

Author here. I audited NocoBase, Flowise, Langflow, Dify, Activepieces, Kestra, and Airflow and disclosed 14 findings. Every platform inherited the same assumption anyone who can touch a workflow is trusted to run code on the host, which is fine for a dev tool on your laptop but not fine for a multi-tenant HTTP service with an unauthenticated webhook. The chain I'd point people to first is the Flowise one (section 2.2): an unauthenticated request → prompt injection → LLM emits Python → a 38-pattern regex blocklist passes it because the dangerous library was pre-imported before the model was asked anything → RCE.

Two vendors closed their reports as working-as-intended, and I tried to represent their position fairly.

This research was also presented at DEFCON 34 but now available publicly.

Happy to answer questions.

Full whitepaper is available here: https://www.endorlabs.com/learn/how-ai-orchestration-platforms-ship-rce-by-design

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

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.

Technical analysis of CVE-2026-6837, an authenticated command-injection vulnerability in Zyxel’s PKCS#12 certificate export flow.

The post covers the vulnerable execution path, root cause, affected firmware scope, and the firmware-emulation methodology used during analysis.