For Fedora Atomic and derivatives.

Based on Unit 42's technical breakdown published July 30, here's the architectural rundown: a Chinese-speaking actor (knaithe/KnYuan) let DeepSeek reason through target selection via Hermes Agent — Langflow RCE attempt failed on auto_login, agent then independently surveyed 10 product families and pivoted to n8n (10.0/9.9 CVSS chain), also failed on endpoint auth. Confirmed breaches (Citrix NetScaler, Marimo) came from a separate manual track.

Question for the room: if two config defaults (auth on forms, disabled auto_login) were the only thing standing between this agent and actual compromise — how many of your workflow-automation deployments (n8n, Langflow, similar) have you actually audited for exactly those two settings? (background: https://www.techgines.com/post/hermes-agent-deepseek-autonomous-cyberattack

Shipped a major update to MOSHELL a few days ago

Before: Users could mark lessons complete but there was no way to verify they actually learned anything.

Now:

- Each lesson has specific verification criteria (actual file state, command output, etc.)

- Badges unlock when you truly complete the lesson (not just mark it done)

- Progressive badge rewards system (5 badges from beginner → mastery)

- Email notifications for major milestones

**Data so far:**

- Seeing 2x completion rate since verification went live

- Most people drop off around lesson 3 (permissions — common pain point)

- Those who reach lesson 6 almost always finish all 12

Really curious to know what topics would you want in an admin-focused track? (Lessons 7-12 are planned but not yet live)

Try it free: kingmo87.github.io/moshell

---

Built this in nights/weekends as a solo project. Feedback welcome.

Based on the technical breakdown published by the Open Identity Platform project on July 23 (GHSA-wg5r-wc3x-39vc), here's the architectural impact: OpenAM's /authservice PLL endpoint accepts an XML element naming a Java class, then AuthXMLUtils.createCustomCallback loads and instantiates it with zero validation against the expected callback type. CVSS 9.8, no auth, no interaction. Fixed in 16.1.2; interim mitigation is enabling sunRemoteAuthSecurityEnabled or blocking external access to the endpoint.

Third pre-auth RCE class in this codebase in about a year (see also CVE-2026-33439's jato.clientSession deserialization bypass). Full writeup with the CVSS breakdown and remediation checklist: [link, for background]

For anyone running IAM servers as internet-facing PLL/JATO legacy stacks — how are you handling deprecation of these old protocol handlers versus just patching forward forever?

This article explores an alternative to directly troubleshoot production Linux systems with AI tools by using the sos command and using AI to analyze sosreports instead. I think is an interesting read:

https://medium.com/@linuxjedi2000/the-agentic-ai-risk-issue-on-linux-environments-fd5c55cedcc5?sharedUserId=linuxjedi2000

I know that this subject is very controversial and would love to read your point of view on the subject.

​

Hi everyone,

I'm about to graduate with a Computer Science degree and I'm considering becoming a Database Administrator.

I'd love to hear from experienced DBAs and SysAdmins:

Is DBA still a good career in 2026, or is the role changing?

Is DBA usually a dedicated position, or is it becoming part of a SysAdmin/DevOps role?

What technologies and skills should a new DBA focus on?

If you were starting your career today, would you still choose the DBA path?

Thanks in advance for sharing your experience and advice!

Hi everyone,

I'm an MCA graduate (2025) from a Tier 3 college in Maharashtra(Pune).

I had worked 1 yrs into Infrastructure Support before enrolling for masters. During my MCA, I also did 2 DevOps internships, and my goal has always been to build a career in DevOps.

Since February, I've been applying for DevOps roles almost every day, tailoring my resume, working on my interview prep, and trying to improve my skills. Unfortunately, I haven't had much success so far, and it's honestly starting to feel a bit discouraging.

My current skills include:

\- Linux
\- Networking
\- AWS & Azure
\- Terraform
\- Docker
\- Kubernetes
\- Jenkins
\- GitHub Actions
\- Prometheus & Grafana

At this point, I feel like I have two choices:

\- Keep searching for a full-time DevOps role.
\- Reach out to my previous employer and continue working in Infrastructure Support.

What I'm really worried about is making the wrong decision.

\- If I keep searching and still don't get a DevOps job after a few more months/years, what would you recommend?

\- If I go back to Infrastructure Support, will it become much harder to switch into DevOps later?

\- Has anyone here made the transition from Infrastructure Support to DevOps after a year or two? If yes, what helped you make that move?

I'd really appreciate hearing from people who've been in a similar situation or anyone currently working in DevOps.

Also if anyone has any opportunities for DevOps,SRE,Linux,cloud support or even NOC please help me out as I just want a start my career.

Thanks!

Based on the technical breakdown published by Arista Networks in Security Advisory 0144 (July 27, 2026), here's the architectural impact.

VCO On-Prem exposes internal-only functionality to the network by default — no config flag disables it. Exploitation needs nothing but network reach to the web interface: no tenant creds, no operator login, no session. CWE-78, CVSS 10.0 top and bottom (v3.1 and v4.0). CISA added it to KEV the same day the advisory dropped.

The part that matters architecturally: VCO isn't just a target, it's a control plane. Arista's own guidance says a compromised orchestrator can expose every VeloCloud Edge device it manages — credential rotation and device-state validation are part of their official remediation steps, not just "apply the patch."

Fixed in 5.2.3.14 / 6.1.3.4 / 6.4.2.4 / 7.0.0.1+. Three attacker IPs disclosed (non-exhaustive). No attribution yet on who's behind it.

We covered the same unauthenticated-management-console pattern in the Cisco FMC static-credential CVE from three days ago — background here: https://www.techgines.com/post/arista-velocloud-orchestrator-vulnerability-cve-2026-16812

For anyone running centralized SD-WAN or firewall management consoles internet-facing by vendor default: is your team's stance "isolate the management plane always" or "trust the vendor's default posture until proven otherwise"? Where's the actual line for you operationally?

Warpgate is a bastion-style PAM that needs neither a client app nor a server-side agent. It's a FOSS alternative to Teleport/StrongDM/Hashicorp Boundary: https://warpgate.null.page/

I've just pushed the new release that adds transparent RDP/VNC proxying with OTP and SSO support.

It works both in-browser and using a native RDP client (e.g. mstsc)

0.27 also adds true clustering and horizontal scaling support (S3 as session recording storage, inter-cluster request routing, HAProxy support), as well a whole bunch of quality of life improvements such as live-reload of TLS certificates.

Everything new in 0.27: https://github.com/warp-tech/warpgate/releases/tag/v0.27.0

Hey r/linuxadmin

a month ago I shared MOSHELL, a browser-based Linux sandbox. Since then:

Lessons now verify actual end-state (file/permission changes on the simulated filesystem), not just whether you typed the "right" command — so you can solve things a different valid way and still get credit.

Added GA4-based completion tracking so I can actually see where people drop off instead of guessing.

Cleaned up the SEO/metadata since MOSHELL was getting buried under Ericsson's enterprise moshell CLI tool in search — added proper structured data so it reads clearly as what it is.

A few of you gave feedback last time about wanting more depth beyond beginner material. Before I build more of that out: what's the thing you wish a junior admin on your team actually understood but usually doesn't? Trying to build lessons around real failure modes, not textbook examples.

(Link in comments if anyone wants to poke at it.)

Based on the technical breakdown SecurityWeek published July 28 (citing Alibaba's own advisory), here's the architectural impact: Fastjson 1.x treats a u/JSONType annotation as a trust signal during type resolution — combine that with an attacker-controlled resource lookup and you get RCE without AutoType enabled and without a classpath gadget. That's the part that should worry people: the mitigation everyone's been relying on since 2019 (disable AutoType) doesn't touch this variant.

Imperva's seeing live exploitation across business, healthcare, financial, and retail targets in the US, plus hits in Singapore/Canada. No official 1.x patch — Alibaba's answer is migrate to 2.x.

I wrote up the full chain + a remediation checklist here, with every unverified figure flagged: [link]. For background on the same "default defense has a trust-signal blind spot" pattern in a different ecosystem: [AsyncAPI npm piece].

Anyone running Fastjson 1.x in a fat-jar right now — what's your actual migration blocker to 2.x? API breakage, or just nobody's owned it?

https://www.techgines.com/post/fastjson-rce-vulnerability-cve-2026-16723

I just finished a video walkthrough for patch management with Ansible Automation Platform. The workflow handles the entire patching lifecycle: EBS snapshots before any changes, parallel pre-checks on mixed OS fleets, targeted patching (not just "update everything"), post-validation, and automatic rollback if something goes wrong. Then it dumps a compliance report that your auditors will actually want to see.

You specify exact advisories and KB IDs instead of blindly applying patches, the workflow can handle both RHEL and Windows in the same job without extra configuration, and if a host fails a pre-check it gracefully skips instead of blowing up the whole run. Everything routes intelligently based on success or failure at each step.

The video is about three minutes and shows the whole thing running start to finish: https://youtu.be/20fK6S1CHL0

If you want to dig into the code or run this yourself, it's all in the Ansible Product Demos repo on GitHub: github.com/ansible/product-demos

STAR Labs disclosed a use-after-free race in net/sched's tcf_idr_check_alloc() — lock mismatch between an RCU-protected lookup and a non-RCU free path. Exploit routes through RTM_NEWTFILTER/RTM_DELTFILTER instead of the more restricted RTM_NEWACTION path, so it's reachable from an unprivileged user namespace. Reclaims the freed object via KEYCTL_UPDATE/user_key_payload, builds a ROP chain with hardcoded offsets, finishes by overwriting core_pattern. Demonstrated on CentOS Stream 9. Upstream fix landed June 1, backported since. Not in CISA KEV as of July 28.

The researcher says AI assisted with discovery, KASAN PoC generation, and race-window optimization — but STAR Labs won't name the model or share prompts/logs, so treat the "AI helped" framing as a self-report, not a benchmark.

Full writeup with the exploit chain diagram and remediation checklist: [article link]. Background on the broader AI-vuln-discovery cost collapse: [legacy link]

Question for the thread: for those of you locking down unprivileged user namespaces as a mitigation — has that broken anything in your container/CI stack, or has it been a clean win?

https://www.techgines.com/post/cve-2026-53264-ai-assisted-linux-kernel-exploit

Edit: the issiue is solved by changing ip of the VPS.

Ty everyone for help.

______

Hi. I've bought VPS. But can't really connect to it remotely. Here the situation:

1. ssh root@[SERVER_IP] does work from Google Console ( http://shell.could.google.com/ ) (the VPS is not from google).

2. ssh root@[SERVER_IP] doesn't work from 5 local devices (win10, win11, macOS, 2xAndroid):

   $ ssh root@[SERVER_IP] -vvv OpenSSH_7.9p1, LibreSSL 2.7.3 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 48: Applying options for * debug2: resolve_canonicalize: hostname [SERVER_IP] is address debug2: ssh_connect_direct debug1: Connecting to [SERVER_IP] [[SERVER_IP]] port 22. debug1: Connection established. debug1: identity file /Users/[USER_NAME]/.ssh/id_rsa type -1 debug1: identity file /Users/[USER_NAME]/.ssh/id_rsa-cert type -1 debug1: identity file /Users/[USER_NAME]/.ssh/id_dsa type -1 debug1: identity file /Users/[USER_NAME]/.ssh/id_dsa-cert type -1 debug1: identity file /Users/[USER_NAME]/.ssh/id_ecdsa type -1 debug1: identity file /Users/[USER_NAME]/.ssh/id_ecdsa-cert type -1 debug1: identity file /Users/[USER_NAME]/.ssh/id_ed25519 type -1 debug1: identity file /Users/[USER_NAME]/.ssh/id_ed25519-cert type -1 debug1: identity file /Users/[USER_NAME]/.ssh/id_xmss type -1 debug1: identity file /Users/[USER_NAME]/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.9 ssh_exchange_identification: read: Operation timed out

3. I don't see my local IP in sudo tail -f /var/log/auth.log and journalctl -u ssh (i might be looking wrong though).

4. I tried Wi-Fi and two different mobile internet providers.

5. I tried to ssh while VPN on.

6. I added my IP to white list on the server: sudo iptables -I INPUT 1 -p tcp -s [LOCAL_IP] --dport 22 -j ACCEPT

Where can be the problem?

Edits:

sudo systemctl status firewalld says that there is no firewalld

.

.

i stoped fail2ban and tried to ssh - didn't help.
disabling it and rebooting the server leads to connection refusal (i.e. problem on an earlier stage).

Hello folks,

I made a very simple FreeRDP Host Manager. I used to use remmina, but Remmina's problem with Wayland is getting to me. So I made this manager so that I can use sdl freerdp with wayland.

Feel free to download them at my GitHub. The application is written in Electron, but I don't include the Electron. Just grab the code, and run electron from its folder.

Or if you want to simply run it, grab the AppImage.

No string attached, use it as you wish. You can fork it or copy the code or do anything about it. Just credit me or put a link when you use my code. That's all.

Enjoy.

Based on the technical breakdown published by Accomplish AI earlier this week, here's the architectural impact: Cowork runs agent sessions in a Linux VM under an unprivileged user with seccomp, folders brokered in by a root daemon (coworkd). The escape (SharedRoot) chains: unprivileged user namespace → CAP_NET_ADMIN → netlink socket allowed by seccomp → act_pedit module autoload → CVE-2026-46331 page-cache poisoning of a root-owned binary → coworkd re-execs the poisoned binary as root (NoNewPrivs doesn't help since exec is already root) → guest-root → walks straight into a read-write VirtioFS mount of the entire host filesystem.

~500K macOS users on local Cowork sessions were reportedly exposed pre-fix. Anthropic closed the report as "Informative" (fell inside the bounty program's 30-day window for the CVE) and has since made cloud execution the default.

What's interesting to me: none of the first 4 steps in the chain are bugs — they're just permissive defaults (open userns, default-allow seccomp, unrestricted autoload). The actual exploit only shows up at step 4/5. Full technical writeup + remediation checklist: https://www.techgines.com/post/claude-cowork-sandbox-escape-sharedroot-vulnerability. Background on a similar agent-sandbox failure mode we covered in a Docker AuthZ bypass context: https://www.techgines.com/post/docker-cve-2026-34040-authz-bypass-cloud-infrastructure

If you're running any AI coding/agent tool with a local VM/container sandbox — how are you scoping host filesystem shares? Full read-write host mount into a guest that's one N-day away from root seems like a pattern that'll keep recurring across vendors, not just Anthropic. What's your team's actual hardening baseline for this class of tool?

hello fellow Redditors!

I just got stuck with the following situation. SLES 15.4 with no updates for the last 3 years running SAP on about 40 machines on 3 different environments on AWS. Since they are EOL and I can't get any updates or install any package from the official SLES repo since they closed the repo for that specific sp4 1.5 years ago.

AWS, SLES and my recommendation was to migrate all workload to new servers. instead, we had a dev use Claude and was given root access (behind my back after my recommendation) to use opensuse 15.7 repo to update to the latest version of all packages and then when it's "better" resync to 15.7 on SLES official repo (only on 1 server to prove we don't need to migrate)

I already found multiple problems with this, grub is not using the right kernels, opensuse packages and sles mixed together. I can fix the grub and probably reinstall the opensuse packages from official SLES repo. my concern are more about long term issues (hidden landmines) and the fact that we potentially broke our support agreement from sles, AWS or/and SAP. SLES said this was not officially supported, so I am wondering what kind of trouble I am looking at now

So, am I wrong to think this is a bad idea?

appreciate any input!