Think of it as smart curl or wget for downloading and optionally installing any tool or asset from public github repo but not requiring github authentication, no hitting rate limits, figuring out which asset is right for your platform / os / architecture, manually verifying checksums, etc.
But the tool can do much more than that. You can find more usage examples and full docs in the README.md
If you find this useful, spot the repo where auto-detection doesn't work as expected, or have a great idea how to improve it even further - leave a comment or open github issue.
Based on the technical breakdown Oasis Security shared with The Hacker News yesterday (Aug 25), here's the architectural impact for anyone running NemoClaw locally.
NemoClaw is NVIDIA's OpenShell-based reference stack for running OpenClaw agents in a sandbox. On the Windows-host Ollama path, it starts Ollama with OLLAMA_HOST=0.0.0.0:11434 — no auth on that port. Ollama's own anti-CSRF checks (Host header + CORS) get bypassed entirely once you're not on loopback, and a classic DNS rebinding chain (same root cause as CVE-2024-28224 from 2024) lets an attacker-controlled webpage make "same-origin" calls to the local daemon.
The interesting part isn't the RCE-adjacent access — it's what they do with it. The payload hits /api/create and rewrites the model's Go chat template, the thing that renders the structured message array into raw text before inference. Poison that, and your injected instruction gets appended to every system message going forward. It survives the agent supplying its own system prompt every session, because the poisoned text isn't in the conversation — it's baked into how the API renders text. Oasis: "the template is a model-level property invisible to API consumers."
Fixed on macOS/Linux in v0.0.35. Windows/WSL path is still exposed — the newer bind-probe check in the local Ollama proxy (v0.0.106) doesn't even run on those paths.
One thing I couldn't nail down: The Hacker News's writeup explicitly says this finding "carries no CVE identifier," but three other outlets (Security Boulevard, SiliconANGLE, Hackread) cite CVE-2026-65105. Couldn't independently verify a record either way — if anyone here has visibility into NVIDIA PSIRT's tracking, curious which is accurate.
Open question for the thread: for anyone running local inference backends (Ollama, LM Studio, etc.) alongside sandboxed agent frameworks — are you treating the inference API surface as inside or outside your sandbox's trust boundary? Feels like most threat models draw the line at the agent process and stop there.
I have create a new Reverse Proxy/ Load Balancer for Linux on Cloudflare's proxy lib : Pingora. The project is till on 0.x.x version, but I'm working on standardizing everything.
It have fantastic proxy performance, even beats nginx in performance/stability tests with many thousands of concurrent connections.
It would be great to have a human review and suggestions .
Based on the technical breakdown published by CERT Polska and confirmed by CISA's KEV addition, here's the architectural impact:
Vulnerable condition: zimbra-snmp installed + snmp_notify enabled + swatchdog running (default). Unauthenticated attacker sends crafted SMTP input, it hits the SNMP notification handler unsanitized, executes as OS commands under the zimbra user. Zero privilege escalation needed to start reading mail.
Patched in 10.1.20 (July 20). CERT Polska confirmed exploitation Aug 17. CISA KEV + 3-day FCEB deadline followed Aug 21. Shadowserver's scan shows 12,000+ exposed instances, 270+ with compromise artifacts already.
IoCs: unexplained swatchdog restarts in /var/log/zimbra.log, new files in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, /tmp/ owned by zimbra.
Full writeup with remediation checklist: [techgines.com] (background on the same "trusted monitoring channel → RCE" pattern in our TeamCity CVE-2026-63077 piece)
Anyone running ZCS with SNMP trap notifications on — did you have snmp_notify enabled for a real monitoring integration, or was it just a default nobody turned off?
By audit log I mean which IP viewed what type of stuffs. Which ip created what type of stuffs. I looked into passwordpusher and onetimesecret and both of them do not seem to store the actual one time secret in the database. Now I am wondering if it is required at all in a highly regulated industry? Or am I tripping too much?
Often, small setups don't need heavy monitoring software like Prometheus or Grafana just to check if multiple servers or IPs are up and running.
So, I built a quick, lightweight Bash automation script that reads a list of servers from a server.txt file and pings them automatically to check their live status.
How it works:
Reads line by line from server.txt.
Validates the entry using regex.
Sends a ping request and prints out whether the server is running or down.
Check out the snippet below! Always looking for feedback or ways to optimize it. 🚀
I keep SSH configs in dotfiles and some team repositories, and I wanted the same checks locally and in CI. I ended up writing sshconfig-lint in Rust.
The current beta accepts multiple files directly, resolves nested Include files, detects Include cycles and reports the original file and line for every finding. It also has strict mode plus JSON, SARIF and GitHub annotation output.
I avoided an automatic --fix because moving Host blocks or deleting IdentityFile entries can change the effective config in ways that are hard to notice.
The thing that has bitten me more than once about firewall review is that a ruleset is reviewed as text and behaves as a set of permitted packets, and the two do not line up.
First-match evaluation is what breaks the correspondence. A one-line edit is never local. If you tighten a source range on an early rule, a later rule that was shadowed, and therefore dead, can come back to life and start matching traffic that nobody has thought about since it was written. Nothing in a unified diff shows you that. The changed line looks small and the review approves it.
I wrote a tool that does the comparison at the level the firewall actually works at. It takes two rulesets, compiles each into the set of packets it permits, and prints where the sets differ, along with which rules changed status:
NEWLY BLOCKED (permitted before, denied now)
all entries: in not lo, tcp
10.1.0.0/16 -> 10.5.0.0/16 :502 was allowed by rule 04, now denied by rule 05
STRUCTURAL
rule 03 now load-bearing it was redundant before this change
rule 05 now reachable previously shadowed by rule 04
The "now reachable" line is the one I actually built it for.
What it will not do, so nobody wastes their time: single base chain filter tables only. Any user-defined chain, jump, goto or return is rejected with a file, line and column rather than analysed. Docker adds chains, so plenty of real hosts are out of scope today. NAT is rejected for the same reason, since translation changes packet identity in transit and analysing it with NAT ignored would produce confident nonsense. It also assumes return traffic is permitted, which means it cannot verify a stateful policy, only a stateless approximation of one.
There is an HTML report mode that writes a single file with no scripts, no webfonts and no remote images, so it opens on an air-gapped machine. That was not a stylistic choice. A report describing exactly where an air-gapped network's trust boundaries sit is not something you want fetching a CDN when someone opens it. CI greps the generated file for those patterns on every run.
Correctness checking is a differential harness: the ruleset gets loaded into a real kernel namespace and fwdelta's verdict is compared against what nftables does, with fault injection so the harness proves it can fail. Right now that covers the input hook only.
Apache-2.0, and the musl binary is reproducible with the toolchain pinned:
But I’ve definitely seen small environments where the playbooks became more complicated than the thing they were originally automating. At some point you’re maintaining roles, variables, inventories and handlers just to make a change that would have taken two commands.
Automation is great when it removes work. It’s less great when you create a new system that needs maintaining instead.
Based on the technical breakdown Adversa AI published earlier this week, here's the architectural impact for anyone running or securing LLM agents with code execution + tool access.
The core idea isn't new-new — indirect prompt injection via fetched content has been around since 2023. What's different here is the delivery channel. Instead of shipping a plaintext or weakly-encoded (base64/ROT13/substitution) instruction that a classifier or the model's own weights could decode and flag, the attacker ships real AES-256-GCM ciphertext plus PBKDF2 key material on an ordinary webpage. A static input filter reads text; it doesn't execute code. Ciphertext is just noise to it — there's no in-weights shortcut the model can take to "read through" strong encryption the way it can with a Caesar cipher.
So the model has to actually run the decryption in its own sandbox to make sense of the page. And that's the pivot: the decrypted plaintext now exists in context as *the output of code the agent itself just executed*, not as untrusted fetched content. Per Adversa, the model applies materially less scrutiny to its own runtime output than to something pulled from an external page — it's treated closer to internal state than user input.
Demonstrated against xAI's Grok (grok.com, reportedly Grok 4.5 Fast): a user asks Grok to summarize a page, the page decrypts into instructions telling Grok to resolve private session context (name, coarse location, subscription tier, full conversation history), disguise it as a "decryption key" string, and open a URL "for additional context" — which fires Grok's own privileged navigation tool and ships the data to an attacker endpoint via query params. Zero confirmation step, no visible warning in the PoC.
Second demo against Gemini 3 Flash (Deep Thinking) uses a fabricated Python traceback as the decrypted payload to fake a safety-policy-deactivation callback — different goal (safety bypass vs exfil), same trust-laundering mechanism.
Disclosure timeline per Adversa: reported to xAI June 3, 2026, direct + HackerOne. Acknowledged, no fix timeline given. Still reproducible as of Aug 19, 2026. No CVE assigned.
Worth flagging: Adversa is the sole source for the Grok finding, the 40% success-rate figure is self-reported with no independent replication I've seen, and there's no confirmation of in-the-wild exploitation. Treat those as claims, not settled facts, until someone else reproduces it.
Adversa's mitigation framing is entirely harness-layer, not model-layer — quarantine untrusted content in a tool-less/credential-less context, gate outbound/irreversible actions on fully resolved arguments, capture per-session tool traces, and alert on the sequence (opaque blob + decrypt instruction) rather than any single payload.
For context on the same class of failure (agent can't separate its own trusted state from attacker-supplied data) in a different product, see our earlier GrafanaGhost breakdown.
For anyone running agents with code-exec + outbound network access in production: how are you actually separating "decrypted/derived-from-fetched-content" arguments from arguments that originated in your own system prompt before they hit a privileged tool call? Provenance tagging at the harness level, or something else?
I've been working on BoostLock, a root-only Linux daemon for keeping CPU boost available during idle periods.
The part I care about for an admin is startup failure. In 0.2.0, BoostLock discovers each cpufreq policy, builds one write plan, snapshots the values it will touch, and opens every planned path before the first change. A failed preflight leaves the machine alone. If a later write fails, completed writes are restored in reverse order.
The same transaction includes any writable boost, EPP, EPB, PM QoS, or cpuidle controls. Status shows which policy was changed and which controls were skipped. stop restores the captured state; after kill -9, sudo boostlock restore is the recovery path.
This still needs physical testing across different drivers. It requires root and can increase idle power and temperature. I'm looking for feedback on whether the transaction and status output are enough for an operator to trust what it changed.
Based on the technical breakdown published in the GitHub Security Advisory (GHSA-7gwp-5pfp-969j, mirrored on GitLab's Advisory Database) and watchTowr Intel's honeypot telemetry, here's the architectural impact of CVE-2026-64849.
MLflow shipped an SSRF guard in 3.10.0 (_validate_webhook_url() in mlflow/utils/validation.py) that resolves a webhook's hostname and blocks private/reserved IP ranges. The gap: the delivery component (mlflow/webhooks/delivery.py) follows HTTP redirects without allow_redirects=False and never re-pins the resolved IP after a redirect. Host a public HTTPS endpoint that passes the initial check, respond with a 302 to 169.254.169.254, and MLflow follows it blind.
What makes this worse than a typical blind SSRF: the unauthenticated POST /api/2.0/mlflow/webhooks/{id}/test endpoint reflects the full upstream response status and body back to the caller. Default mlflow server deployments run without auth and expose this webhooks API out of the box. So this is an unauthenticated remote attacker reading your instance's IAM credentials directly in an API response, not a blind timing-based exfil.
watchTowr's Attacker Eye reports scanning activity against cloud-hosted instances within hours of CVE assignment (Aug 17-18, 2026). Affects all versions <3.15.0.
For context on why this pattern keeps recurring in ML/AI infra specifically: MLOps tooling tends to get deployed fast, iterated on by data science teams rather than platform/security teams, and left running past the "just testing this out" phase — often with an attached cloud identity nobody audited. Background on a structurally similar SSRF-to-cloud-metadata chain we covered in industrial/OT infra: [techgines.com link, footnote]
Anyone else seeing MLflow Tracking Servers in their environment that predate a proper platform-team handoff? Curious how people are handling auth/network isolation for MLOps tooling that wasn't designed with a hostile network in mind — reverse proxy with OIDC in front, or something more locked down at the VPC layer?
As a platform architect working in private/public networks here’s a problem I never quite figured out how to do elegantly: Provide retrospective change control evidence for your Linux fleet. Patch on the one, access to enable patching on the other. Proving “Who was authorized to touch this machine on this day, and was it done with consent” involves stitching three different sets of logs together.
Screenshot is from a seeded demo lab, not a customer fleet.
Praxis is the product of thinking I could do better.
Self-hosted. v1.0 has been quietly available for a week or so now to hammer on my hardware as I’m setting it up for others, time for the official release. Central design idea that seems most important: The FastAPI backend is the single source of truth for auth, policy, and audit. All activity, including the actual patching, and the decision to allow someone to take action on a given machine, all transit through this central point.
Hence your records are all recorded into one database chronologically, instead of being assembled piece by piece.
The means of accessing machines to perform the changes are designed for security with minimal attack surface. We use SSH for access and we leverage OpenBao to provision dynamically signed, short-lived certificates to avoid distributing and managing static, persistent keys and certs. The certificate principal is an immutable praxis-user-<id> rather than a login name, so the audit trail stays intact even if someone's username changes.
Users are assigned roles with privileges defined as admin, maintainer or auditor. Higher value commands will require step-up auth (totp/oidc). Patching process is driven by staged roll-outs, managed repository access for apt & dnf, and a “rings of trust” model – you push to the innermost ring, watch how it behaves, and then roll out further.
To jump ahead of the likely first three questions, this does not substitute for Ansible or Puppet, which do push state, while Praxis does not do config management. Run them both. Similarly, this does not compete head to head with Teleport or CyberArk.
Same case, this is not goign to head to head to Teleport, CyberArk etc. They're ahead of me on broad reach of access, and that's and I won't lie on that one.
But where was I couldn’t find a single thing where the approval of a change, the granting of access to implement that change, and the verification required to pass an auditor could live in the single shared record. And that’s the void I built this for. If you’ve already got a Satellite, a bastion, and a patch database stored in a spreadsheet that’s working out for you, this product may not be for you.
Praxis runs on your hardware only – no cloud, no telemetry, no call home and a free tier of 15 machines.
What we are not building in V1.0: We’re focused on the patch and access management part; No CRL or OCSP in 1.0, so there is no revocation path for issued certificates. Lifetimes are short by design, but that is a real gap and I am not going to dress it up. As a first pass, we do not manage automated purge policies for audit logs - you manage them. We can provide the evidence, not the attestation of compliance.
Based on the technical breakdown published by Hadrian Security (researcher Melvin Lammerts) and vendor advisories from GeoTools/GeoServer, here's the architectural impact:
**Disclosure timeline:** u/q1uf3ng dropped the vuln on X Aug 12, 10:46 UTC, no CVE at the time. watchTowr told The Hacker News they saw exploitation probes within hours — hundreds of attempts from a small IP pool. GeoServer/GeoTools shipped fixes Aug 14–15 (GeoServer 3.0.1/2.28.5/2.27.6, GeoTools 35.1/34.5/33.6), tracked as GHSA-mqjf-5f49-2fjh, CVSS 9.8.
**Root cause:** jsonArrayContains(<col>,<pointer>,<value>) in GeoTools' PostGIS datastore handling drops <value> straight into a `jsonb_path_exists()` PostgreSQL expression via String.format() — no escaping, no bind param (jsonpath doesn't support bind params in Postgres, which is presumably why someone reached for string formatting here). Reachable pre-auth through public WFS/WMS OGC endpoints via CQL_FILTER.
**Interesting bit for anyone doing exploit dev/detection eng:** the SQL shape differs by GeoServer service. WFS 2.0 wraps the filter in a derived-table count subquery (for numberMatched), which traps a stacked-query semicolon inside the subquery and blocks the obvious RCE route. WFS 1.0 skips that wrapper, landing the injection directly in the top-level WHERE clause — that's the route Hadrian used to reach `COPY ... TO PROGRAM` RCE (confirmed against a local 2.26.1 + PostGIS 15 lab, landed shell as uid=999 postgres).
Without superuser/pg_execute_server_program, injection still works for error-based (CAST AS int) and time-based (pg_sleep) extraction — doesn't need preferQueryMode=simple either, contrary to the commonly cited 2023-era mitigation.
**The regression angle:** GeoTools' own advisory states this is a regression of CVE-2023-25158, and explicitly notes the 2023 mitigation (prepared statements + disabled encode functions) does NOT work against this variant.
**Question for the thread:** for anyone running GeoServer with PostGIS in production — is disabling the "encode functions" option on the datastore (Hadrian's suggested interim mitigation) actually viable for you without breaking existing CQL filter usage, or does that break real filter functionality in your deployments?
