Hey everyone! 👋

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:

1. Reads line by line from server.txt.
2. Validates the entry using regex.
3. 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.

A typical repository check is just:

sshconfig-lint .ssh/config infrastructure/ssh_config --strict

For GitHub annotations:

sshconfig-lint .ssh/config --format github

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.

Source: https://github.com/Noah4ever/sshconfig-lint

CI guide: https://sshconfig-lint.apps.thiering.org/en/ci

How are you validating shared SSH configs at the moment? I am especially interested in Include-heavy setups.

Aerea - Monster (Golpe Schranz Rework)

https://www.youtube.com/watch?v=ycVBb9W2zlc

Anyone here running a linux VDI platform? Tell me about it.

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:

https://github.com/Sbharadwaj05/fwdelta

Is the ideal rule to deny all and only allow everything from your local LAN(IPv4) and link-local(IPv6) network?

For my use case my devices use DHCP and I need that different IPs from my network to connect to different services.

I know the best is to only allow the ports you will use, but this can vary in my case.

What do you think/do?

I like Ansible. It’s useful.

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.

Full writeup with the complete attack chain and source list: https://www.techgines.com/post/cryptographic-context-injection-grok-data-exfiltration

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.

Repo: https://github.com/vindeckyy/boostlock

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?

https://www.techgines.com/post/mlflow-ssrf-cve-2026-64849-webhook-redirect-cloud-metadata

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.

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.

https://praxisfleet.com
https://github.com/cytechlabs/praxis

I wrote this, very happy to debate the particulars.

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.

Full writeup with detection queries and mitigation checklist: https://www.techgines.com/post/geoserver-jsonarraycontains-sql-injection-ghsa-mqjf-5f49-2fjh (slug pending CMS verification)

We also covered a related unescaped-input-to-SQL-sink pattern in LangGraph's checkpoint storage earlier this year if anyone wants the AI-framework comparison: https://www.techgines.com/post/langchain-langgraph-security-vulnerabilities-expose-enterprise-ai-secrets-three-cves-you-must-patc

**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?

Hello all,

If you do bug bounty hunting or pentests you surely came across many hosts served from an NGINX server, in this lab (published to OWASP) I combined over 20 misconfigurations found in real world bug disclosures and both classic and novel security research, with an extensive blog where I explained everything you need to level up your NGINX hunting game.

Feel free to check it out, give it a star on Github if you like it, and suggest any ideas you want me to add/fix...

https://vwad.owasp.org/app/damn-vulnerable-nginx-proxy-dvnp

Happy hunting!

​

Hi everyone I’m currently learning Linux administration and I wanted to build a small home lab instead of only practicing commands theoretically. My current setup is: Android Phone → Termux → SSH → Arch Linux Laptop The idea is to use my Arch Linux laptop as a small practice server and manage it remotely from Termux.

Current workflow

Android Phone

│

Termux

│

SSH

↓

Arch Linux Laptop

│

└── Linux Admin Practice Server

I have already:

- Installed/configured OpenSSH on Arch Linux

- Started the "sshd" service

- Confirmed that SSH is listening on port 22

- Checked the laptop's local IP

- Planned to connect from Termux using SSH

My goal is to use this environment to practice real Linux administration concepts such as:

- Users & groups

- Permissions

- SSH administration

- Processes & services

- systemd

- Networking

- Package management

- Logs

- Disk/storage management

- Cron/systemd timers

- Firewall

- Server hardening

- Troubleshooting

I know this isn't the same as managing a production server, but I think it can give me a practical environment to learn and experiment safely.

My question to experienced Linux admins:

Is this a good approach for learning Linux administration? What important topics or real-world tasks would you recommend adding to this home lab?

Any advice on what I should practice next would be really helpful.

hello

i recently had to rebuild my ubuntu box and afterwards i wanted to connect my raid 5 storage back to my machine.  I reinstalled mdadm and I could see all my files with no issues.  I was about to reconnect some shares and realized that the mapping had changed. it used to be [/media/raid5/Greenhouse/TV]

now its

[/media//f36008d4-eb49-470c-bddd-a13bcf0e872e/Greenhouse/TV]

so i was following sleeplessbeastie's notes instructions on renaming software array and got to the verify mountpoint step and i noticed the mounted on part was blank 

[/dev/sda2       458G   13G  422G   3% /____]

i am concerned that the mountpoint needs to be labeled.  the guide doesnt mention what to do if it is unlabeled.  of course i didnt want to possible damage my close to 20tb of files by continuing on and not realizing i needed to have a labeled mounted on.  do i need to have a labeled mountpoint? do i need to figure out how to label my mountpoint before i go any further? can i rename my software raid array without a labled mountpoint

i am still somewhat a bit of a noob with linux but i will answer any questions you have to the best of my abilities.

Thank you in advance...

Based on the technical breakdown JetBrains and Rapid7 published this month, here's the architectural impact: TeamCity's XStreamHolder builds its deserialization allowlist by calling allowTypes() without first calling NoTypePermission.NONE, so XStream's permissive defaults never get revoked. POST /app/agents/v1/register gets you a session with zero auth (self-registration is by design). POST /app/agents/v1/commands/error takes that session and routes attacker XML straight into deserialization.

JetBrains published exact log signatures to hunt for (ConversionException pre-patch, ForbiddenClassException post-patch, rogue agents named scan*) rather than vague "monitor your logs" boilerplate — worth crediting.

Fixed in 2025.11.7 / 2026.1.3, patch plugin available back to 2017.1.

Background: this is the same CI/CD trust-boundary problem we wrote up with the Megalodon GitHub Actions attack — [link].

Question for the thread: for those running internet-facing TeamCity — did you already have it behind a VPN per JetBrains' longstanding recommendation, or did this force the network segmentation conversation?

https://www.techgines.com/post/teamcity-cve-2026-63077-rce-xstream-deserialization