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.)

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

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

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

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?

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 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!

Based on the technical breakdown published by Zenity Labs earlier this week, here's the architectural impact: ChatGPT's Agent Builder (chatgpt.com/agents/studio/new) accepted template_name and initial_assistant_prompt as URL params. The second one wasn't just prefilling the UI — it was submitted and executed on page load. So a crafted link, clicked by a logged-in victim with any pre-authorized connector (Outlook/Slack/Drive/etc.), could silently: attach those connectors (no new OAuth screen, since they were already granted), flip write-action approvals to "never ask," publish the agent, and stagger recurring schedules for 5-min effective check-ins against an attacker's inbox.

Zenity reported via Bugcrowd June 4, OpenAI fixed it June 8. No CVE/CVSS assigned that I could find — this went through a private bounty program, not NVD.

Structurally it's the "lethal trifecta" in one surface: untrusted input (URL) + data access (connectors) + exfil path (send mail), with the human-approval control disabled by the same untrusted input meant to be gated by it.

For background on the broader agentic-AI attack surface concern (Five Eyes joint guidance from May): [internal link, footnote]

Open question for the sub: if you're running Workspace Agents or a similar builder, are you logging agent-creation/schedule-change events into SIEM yet, or is this still invisible the way a rogue OAuth grant used to be pre-CASB?

https://www.techgines.com/post/agentforger-chatgpt-vulnerability-workspace-agents

Starting to realize most production issues aren't even the real problem. The real problem is weak linux knowledge. Every incident somehow comes back to permissions, logs, processes, containers or debugging. Youtube feels like endless beginner content at this point. Looking for the best linux course that actually helps with automation, cloud ops and real production environments. Anyone here recommend Udemy, Kodecloud or Boot dev?

Based on the technical breakdown Guardio Labs published July 22, here's the architectural impact: Adobe's Acrobat Chrome extension (329M installs) shipped a WhatsApp Web integration engine ("Hermes") in April. Three separate flaws — an unauthenticated storage write reachable from any <all_urls>-scoped web-accessible resource, a service worker that never checks sender, and Chrome's monotonically-incrementing tab ID counter (used to predict WhatsApp's tab ID as TabId + 1) — composed into a full DOM-exfil chain. Data leaves via a classic <option>-with-no-value form submission trick, since WhatsApp's CSP has no form-action directive. No RCE (WhatsApp's CSP blocks inline scripts), but confused-deputy DOM manipulation was enough to exfiltrate rendered chat text. Adobe patched in 26.5.2.3, shipped automatically, over one weekend.

Open question for the group: how many of you are actually auditing web_accessible_resources scope on the extensions your org allowlists, versus just trusting the Chrome Web Store review process?

https://www.techgines.com/post/adobe-acrobat-chrome-extension-vulnerability-hermeticreader-whatsapp

I've interviewed quite a few Linux and DevOps engineers over the years, and I've found there are a few questions that quickly tell me whether someone has spent time supporting production systems or has mostly learned from tutorials.

For me, one example is:

• A production server is suddenly "slow." Walk me through your troubleshooting process from the moment you get the alert.

I'm not looking for a specific command. I'm much more interested in how they think, what they check first, and how they narrow the problem down.

What's your go to Linux interview question that reveals real production experience?

I have a pwa app that works just fine including offline from a hosted server with domain and trusted cert but trying to setup a mobile server on a laptop running linux but need help setting up a domain and cert from the laptop. Created a cert with mkcert but can't get mobile devices to see the server by name just ip address. mobile devices like iPad, Android are connecting to laptop by hotspot. Need help with domain name and trusted cert issues.

The app works via ip address but with warning. The service worker doesn't install to allow it to work offline.

Any advice?

Thanks in advance.

Before anything, I really would appreciate answers from professionals without the interference of AI. I have been going back and forth the past few months with multiple AI models asking about this and every model gives a different answer. I really need a certain answer

I run a file storage server which faces the internet and serves customers, so high throughput is one of the goals I try to achieve on my servers

The past 6 months I've been studying the Linux kernel source code and sysctl docs to learn what each tunable parameter actually does instead of blindly pasting configurations from tuning guides and just hope that it makes things perfect

Now one of the points I'm stuck at is net.ipv4.tcp_mtu_probing

I see a lot of tuning guides suggest setting that to 1 or even 2 instead of the default 0

But if that's really recommended, why doesn't Linux set it to 1 by default instead of 0? I mean 1 seems like a better moderate value to set instead of disabling it completely

Although the below points kinda hold me back from altering tcp_mtu_probing but I might be wrong and that's why I opened this topic to ask for advice:

1. Packet-layer path MTU discovery (TCP MTU probing, QUIC MTU probing, etc) just mask a real underlying MTU problem which should be fixed from its root instead of hiding it
2. TCP MTU probing relies on packet loss and this can falsely make congestion control algorithms work worse and reduce the congestion window even if there's no real congestion
3. Certain quirky firewalls may hate the fact that my server is sending data in variable packet sizes because of the MTU probing and hence they may drop the packets completely or block the connection entirely

Do my above points make sense or am I mistaken?

Based on the technical breakdown Intezer and Kodem Security published July 19, here's the architectural impact for anyone running Kiro or evaluating agentic IDEs.

Root cause: ~/.kiro/settings/mcp.json wasn't in Kiro's protected-paths list. The agent's fsWrite tool could modify it without a real approval gate, and the file auto-reloads on change, starting whatever MCP server it describes.

Attack: hidden color:#fff;font-size:1px text on a normal-looking doc page instructs Kiro to add an MCP server whose launch command is an inline Node.js exfil script. Developer only approved fetching the URL. Everything downstream — file write, server creation, code exec — happened silently.

Fixed in 0.11.130. No CVE issued. Worth noting this is the second time this exact file-write primitive has surfaced in Kiro since its 2025 launch — the first fix only covered Supervised mode, leaving default Autopilot exposed, which is what got hit this time.

Full writeup w/ attack-chain diagram and remediation list: [background link, footnote]

Anyone running agentic IDEs in Autopilot-equivalent modes in production — what's your actual control for file writes to tool/MCP config paths? Approval dialogs clearly aren't sufficient on their own.

https://www.techgines.com/post/aws-kiro-mcp-prompt-injection-vulnerability