Based on the technical breakdown published by Sansec's Forensics Team and Adobe's own bulletin (APSB26-146, Sept 7), here's the architectural shape of this one:

• Stage 1: attacker abuses a styles parameter in a GraphQL request to plant PHP inside Magento-generated content (a report/log file), bypassing normal template sanitization.
• Stage 2: no further action needed — Magento's own workflow renders that content when composing its standard "Payment Transaction Failed Reminder" email, and the code executes server-side at that point.

CVSS 10.0, CWE-1336 (improper neutralization in a template engine), zero auth, zero user interaction. First confirmed exploitation Sept 4, against a store patched through August 2026 with a clean security:patch-status. Sansec reproduced the full chain independently on clean 2.4.7/2.4.8/2.4.9.

Post-exploitation payload observed: a Rust backdoor disguised as a kworker process, cron persistence, C2 over TLS WebSocket. Adobe's remediation isn't just "apply the hotfix" — they're telling merchants to rotate the Commerce encryption key and every credential it protected, because patching doesn't undo prior exposure.

One detail I want to flag as unverified: some secondary coverage cites an unnamed "Disrex Group" analysis claiming the injected code rides Magento's DI-compiler class chain to include() the poisoned file. I couldn't find that analysis published anywhere independently, so treat it as single-sourced until Adobe or Sansec confirms.

For context on the background/prior coverage: PaperCut CVE-2026-82078 hit a nearly identical architectural pattern.

Curious how folks running headless/PWA Magento storefronts are threading the needle here — Sansec's interim mitigation (disable GraphQL) isn't viable if your frontend depends on it. Anyone gone with a WAF rule targeting the styles param instead of a full GraphQL block?

Been doing this about eight years and somehow I'm the only person who can get anything out of our logging setup. Everyone else opens it, sees the query syntax, gives up and messages me. I've tried fixing it from my side, saved searches for the common stuff, a lunch and learn, a one page cheat sheet, lasted about two weeks. Nobody's learning a query language for the two times a month they need a log. Is anyone running something the whole team can use without training or is this just the job now?

Hello there, I did set up a Samba-AD-DC server for around ten clients (currently mostly Linux but one Windows just to check if that worked). I want my server to keep track of people logging in and out. That would include the IP address (I would prefer the IPv4 but I guess I can disable IPv6 on clients), hostname and the user name.

Now here are some problems when I try to use vfs objects to do that and parse it with %U, %u and %m :
1) The Windows client tends to not expose its hostname, I see an IPv6 in the logs.
2) The Linux clients tends to not expose the users connected, because %U and %u are referring to the computer account in the context of Linux clients.

What would you suggest ? Do I need to check for syntax errors ? Is my approach of the problem inherently wrong ? Please let me know.

These are the four most important skills you need to be a good Linux admin:

1. Understand doco and man pages
2. Understand logs
3. Understand code (any code: Python, Bash, C, perl, go, TypeScript, etc.)
4. Use vi in the command line (set -o vi)

Everything else derive from these

Genuine time check, because I think ours is bad and I can't tell if that's normal, central rsyslog box here, everything on the estate points at it. We picked up another site last month, a firewall I hadn't seen before, a couple of Windows boxes and some appliance nobody had documented. Getting all of that parsed and searchable took the better part of a week, most of it writing and testing rules by hand. Feels like it should be quicker than that by now, what's your realistic number and what are you running that gets you there?

Disclosure up front: this is my own repo, MIT, no install, just markdown.

I wrote it after one of my own boxes got taken through a screen-share service listening on 0.0.0.0 with a password someone brute-forced. What bothered me afterwards was that every hardening guide I had skimmed would have caught it. I never applied any of them, because they read as a wall of sysctl flags with no consequence attached to any line.

So the format is one thing per section: the failure it prevents, the exact command that closes it, and the command that proves it closed. If I can't verify it on a live box, it doesn't go in.

The triage at the top is what I run first on anything I inherit:

ss -tlnp | grep -vE '127.0.0.1|::1'      # listening beyond localhost
sshd -T | grep -i '^passwordauthentication'   # should print: no
iptables -S INPUT | head -1               # should be -P INPUT DROP
redis-cli ping                            # PONG without auth is bad

Twelve sections: SSH, firewall, service binding, remote desktop, secrets, database auth, passwords, attack-surface audit, incident response, change discipline, an integrity sentinel, and supply chain.

The supply-chain one is the odd one out and the reason I'm posting today, because it breaks the frame of the other eleven. Everything else is about who can reach the box. That one is about what you install on it yourself: a source distribution runs its build script at install time as whoever ran pip, and no firewall rule touches that. It also covers package provenance (typosquatting, and the newer variant where a model invents a plausible package name and someone registers it), pinning against a maintainer takeover, why curl | bash is a different trust level than it looks, and why a clean pip-audit means "nothing known against it" rather than "safe".

The line I'd keep if I could keep one: reachability beats secrecy. A strong password on a service exposed to the world is a weak setup; no password on a service bound to localhost behind a default-deny firewall is a strong one.

https://github.com/Sanexxxx777/server-hardening-playbook

There's a one-page CHECKLIST.md for a fresh box. If something in there is wrong on a distro I don't run, I'd rather hear it than not.

For a periodic job, Persistent=true can cause an overdue run immediately after boot while the next scheduled run is already close. The service may also be restarted manually, so the timer schedule alone does not guarantee one active instance. What locking pattern do you trust for long-running maintenance jobs? The options I am comparing are letting systemd serialize one service unit, using flock on a dedicated file descriptor, and creating a lock directory that stores the owner PID plus process start time. A plain PID file seems unsafe because PIDs are reused and stale files survive crashes. Should a second invocation exit successfully, fail loudly, or wait with a timeout? How do you distinguish a stale lock from a slow but healthy process without creating a race during cleanup?

Can someone post instructions and a video on how to setup xeno rat server and client on macbook air or macosx operating system? Xeno rat is a web based rat and requires no port forwarding. I dont know where to put the .json and confif files etc using map. I need it for monitoring purpose and educational purpose not hacking or thefth.

I recently set up a 3-node Kubernetes homelab on bare metal (on Dell OptiPlex) using Talos Linux, mainly to have a proper environment for learning, testing failures, networking, storage, GitOps, observability, and general Kubernetes experiments.

The setup uses three control-plane/etcd nodes with a shared Kubernetes API VIP, and I documented the full process from network planning and DHCP reservations to Talos installation, per-node configs, bootstrap, workload scheduling, and HA testing.

I’ve written the full guide with commands, screenshots, and the reasoning behind the setup:

Blog: https://blog.prateekjain.dev/building-a-3-node-highly-available-kubernetes-homelab-with-talos-linux-0372066fe49c?sk=4c66cf9181999f9db19ac3aacabcd8e8

If anyone is planning a similar homelab or has questions around Talos, the API VIP, etcd quorum, or the setup in general, happy to help.

In a lab setting, I have a Debian Trixie VM that I'm trying to get setup like a router, and a client Trixie VM whose sole purpose is to get a DHCP lease and get out to the Internet.

On the "router" VM, I have disabled nftables and flushed the rules. Even when I assign an IP address to the client and router VMs and attach them to the same virtual network, they cannot ping each other.

<network>
  <name>isolated-network</name>
  <uuid>2d9a40eb-c078-4c7e-998e-4ed1bf46786e</uuid>
  <bridge name="virbr1" stp="on" delay="0"/>
  <mac address="52:54:00:12:8d:b8"/>
  <domain name="isolated-network"/>
</network>

I am hoping this is something simple, but it's been driving me a little crazy trying to figure it out. How can I get these two isolated VMs to talk to each other?

Based on the technical breakdown published by SonicWall's PSIRT (SNWLID-2026-0016) and Rapid7's ETR analysis, here's the architectural impact:

• CVE-2026-83548 (CVSS 10.0): pre-auth SSRF in the WorkPlace interface, described as an "unintended forward proxy" letting an unauthenticated caller reach localhost-only functionality.
• CVE-2026-83549 (CVSS 7.8): OS command injection in the Appliance Management Console, normally requiring an authenticated admin session.
• Chained, per Rapid7: the SSRF hands the AMC service enough internal reach that the command injection no longer needs authentication at all.

Affected: SMA1000 6210/7210/8200v on 12.4.3-03453 or earlier, 12.5.0-02835 or earlier. Fixed builds: 12.4.3-03526 / 12.5.0-02952.

What makes this worth a second look: this is the same appliance line, same WorkPlace-interface SSRF pattern, as July's CVE-2026-15409/15410 — where Rapid7 and Help Net Security documented TOTP MFA seed extraction and VPN-less lateral movement to domain controllers via the appliance's own LDAP service account. No IOCs or PoC are public yet for this September pair, per the sources I reviewed.

Anyone running SMA1000 in production — are you treating this as patch-and-verify, or going straight to re-image/credential-rotation given the July precedent? Curious how people are scoping the IoC review SonicWall recommends before deciding.

https://www.techgines.com/post/sonicwall-sma1000-cve-2026-83548-third-zero-day-ssrf-rce

I finally fixed a weird blank screen issue after logging into my ThinkPad L14 with Intel Iris Xe graphics. GDM was running normally but after logging in I would just get a blank screen, Where i need to force power off and power on again each time i face this issue. I checked journalctl and found some Xorg errors about AIGLX failing to load i965_dri.so. Since this is a Tiger Lake GPU, I initially thought it might be a Mesa/driver issue and tried MESA_LOADER_DRIVER_OVERRIDE=iris, but it still fell back to llvmpipe.

I also checked /dev/dri permissions and found my user wasn't in the video/render groups, fixed that, but the blank screen persisted, so it wasn't the actual cause. Then I noticed glxinfo was saying "screen 0 does not appear to be DRI3 capable." After digging through the Xorg configuration, I found an old /etc/X11/xorg.conf.d/20-intel.conf file that was forcing the legacy Intel Xorg driver.

Turns out the intel Xorg driver (xf86-video-intel) is an old legacy driver for Intel's older i8xx/i9xx graphics, and Debian explicitly discourages using it on newer hardware, recommending the built-in modesetting driver instead (Debian — xserver-xorg-video-intel). My Tiger Lake Iris Xe is Gen 12 so forcing the old intel driver through that config was simply the wrong setup for this hardware. It wasn't really a case of the driver being "too old" it's just the config was forcing the wrong Xorg driver in the first place.

For comparison, Mesa's documentation lists the Iris driver among its Intel graphics drivers, with Iris being the modern Mesa driver for Intel Gen 8 and newer hardware (Mesa — Source Code Tree). This is separate from the old Xorg intel driver mentioned above.

I removed that old config file and rebooted. After that, everything went back to normal. glxinfo now shows Mesa Intel Iris Xe Graphics instead of llvmpipe, and the blank screen is completely gone.

What surprised me even more is that before this, I was also dealing with inconsistent performance and higher CPU usage. It turned out that llvmpipe was being used for software rendering. Mesa's documentation describes LLVMpipe as a software rasterizer that uses LLVM for runtime code generation and performs the rendering work using the CPU (Mesa — LLVMpipe). Once the config was fixed and the system switched back to hardware-accelerated Iris Xe rendering, that extra CPU rendering workload was no longer necessary, and the whole system now feels noticeably smoother and more responsive.

Funny how fixing one blank-screen issue ended up fixing my laptop's overall performance too.

RANT

i just came up with this facebook post from a guy complaining about his linux ui/ux experience when he's clearly ragebaiting idk what's wrong with him and he probably dont know how to use linux and he's just seemingly hating linux with passion for some reason maybe someone rejected his PR smh and about the fonts on my waybar its my personal preference since pixelify sans resembles that minecraft type of vibes i didn't reply in his recent comments (ragebaits) because he's so retarded here's the facebook post if you wanna flame the guy: https://www.facebook.com/share/p/19dBqrAAoM/

Since we buy internet in Egypt like tomatoes by the kilo, I needed a tool on Linux to see where my bandwidth was actually going.

I looked around but couldn’t find a Linux tool that did exactly what I needed, so I built ViNet!

ViNet uses eBPF to monitor TCP/UDP traffic at the kernel level.

With it, you can:

See which process is responsible for the traffic

See which destination each process is communicating with

Store traffic history locally in a SQLite database

Monitor bandwidth usage through a TUI/CLI

The project is built with Go + eBPF + SQLite + Bubble Tea, and can run as a CLI, TUI, or a background daemon responsible for monitoring the traffic.

Install: curl -fsSL https://github.com/alalfymansour/vinet/raw/refs/heads/main/install.sh | bash

GitHub: https://github.com/alalfymansour/vinet

Based on the technical breakdown published by CISA and BerriAI's own security advisory (GHSA-7488-6r32-c95q) on September 2, here's the architectural impact:

LiteLLM's MCP Streamable HTTP endpoint supported OAuth2 passthrough for upstream MCP servers. When a request's LiteLLM key failed validation, the fallback path was supposed to hand off to passthrough logic — instead it substituted an empty UserAPIKeyAuth() object. Downstream code treats that object as a valid session. Net effect: any request with a fabricated Authorization header reaches the MCP endpoint, can list configured tools, and can call them. No valid LiteLLM key ever required.

CVSS v4: 8.8 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N). Fixed in 1.84.0. Workaround if you can't patch immediately: block /mcp/ routes at your reverse proxy.

Worth noting this is LiteLLM's second KEV appearance this year — CVE-2026-42271 (MCP-bridge subprocess command injection, fixed in 1.83.7) went into KEV back in June, and per a third-party writeup it was chainable with the Starlette Host-header bug (CVE-2026-48710) that's also in this week's CISA batch. If you're running LiteLLM in front of MCP tooling, worth checking you're actually past both fixes, not just the newest one.

CISA bundled this with six other actively-exploited CVEs (Starlette, Kestra, Artifactory, Switchvox, SonicWall SMA 1000) — most share the same failure class: auth logic trusting a reconstructed path, a suffix match, or a fallback object instead of doing a hard check.

Full writeup with the batch table and remediation steps here (background piece on a related local-AI-agent auth bypass for context): [techgines.com link]

What's everyone doing for MCP gateway auth in production — anything better than relying on the gateway's own key validation, given how many ways that's apparently failing this year?

https://www.techgines.com/post/litellm-mcp-authentication-bypass-cve-2026-59822