Based on the technical breakdown published in ServiceNow's own August 2026 CVE advisory (KB3152242) and corroborated by BleepingComputer/TheHackerNews, here's the architectural impact: three independent unauthenticated paths into any exposed instance — one through the GraphQL Composite Data API, one through the system config image upload processor, one through a dynamic ORDER BY clause. A fourth bug (CVE-2026-6876) is a sandbox escape for low-priv users. ServiceNow's telemetry says no active exploitation — but their track record on that claim isn't great (see CVE-2026-6875, caught exploited by Defused before ServiceNow's own advisory admitted it). Full patch table and attack chain: [link, background context: our earlier piece on AI sandbox escapes]

Question for the thread: for anyone running self-hosted ServiceNow instances — are you treating GraphQL batching endpoints as a distinct attack surface in your WAF rules, or still relying on the same generic injection ruleset you use for REST?

A few honesty notes on my end: the "85% of Fortune 500" figure is ServiceNow's own self-reported stat, not independently audited — I flagged that in the article's accuracy table. Worth verifying against ServiceNow's investor materials if it matters for your reporting.

https://www.techgines.com/post/servicenow-ai-platform-vulnerabilities-cvss-10-graphql-sql-injection

Ok it’s your favorite ShittySysadmin

I’m stuck again and need your help.

Someone told me to run netstat and I don’t understand what these numbers mean.

445
1433
3306
21

445 I thought was on windows and this is Linux I think
Or maybe it’s both….can it be both??

Someone else told me to do 62.238.47.215 with some numbers behind it but it didn’t work when I tried it.

Also why does everyone keep typing

# sudo rm -rf /

I don’t know what it means but everyone loves to tell me to type it but it never works for me idk im just a shitty sysadmin

password was changed to poop because it’s easier to type

Please tell me what these ports are and how did they get there?

We have a mix of Linux servers (RHEL, SSSD/realmd joined) in our AD forest going back to 2019. Our compliance/health report flags a bunch of them for PasswordNeverExpires = TRUE, but when I cross-check PasswordLastSet against today's date, the passwords are actually rotating (varying DaysSincePwdChange values, roughly in the 4–30 day range across machines) — so SSSD is clearly doing its job on the client side.

A few questions:

1. Why does the ADS_UF_DONT_EXPIRE_PASSWD bit (0x10000) get set on Linux-joined computer objects in the first place?

My understanding is adcli used to set this bit unconditionally from its original 2012 release until v0.9.2 (2021), when it was made optional behind a --dont-expire-password flag. Some of our newer machines (joined in 2026) still show the flag set, which suggests either our join automation is still passing that flag, or something else is setting it.

2. Does the flag actually do anything on a box where SSSD is actively rotating the password?

Per Steve Syfuhs' writeup, DCs don't enforce password expiry for computer accounts — expiry is just a hint for the client's proactive rotation logic, not something the DC checks.

So my read is that clearing the flag on a machine where SSSD is already rotating should be a functional no-op — it just satisfies whatever compliance scanner is checking userAccountControl. Is that correct, or is there a scenario where this bites you?

3. What's the actual best practice in 2026 for fixing this at scale?

• Bulk-clear via Set-ADComputer -PasswordNeverExpires $false against the whole OU?
• Fix it at the source by auditing our join automation (Ansible/Puppet templates) for a stray --dont-expire-password flag?
• Or is there a way to have adcli update clear the bit itself without a separate LDAP write?

Would appreciate input from anyone who's dealt with mixed Windows/Linux AD estates at scale — especially if there's a gotcha I'm not seeing with ad_maximum_machine_account_password_age (SSSD, default 30 days) vs machine password timeout (Winbindd, default 7 days) that makes bulk-clearing the flag risky.

I am forced to use Xshell by our company. It's either that or raw putty. I much prefer Mobaxterm but it's no longer allowed. For the most part Xshell works ok, however I am finding gaps in features and functionality. How do I do the following?

• Hot key to open session manager? I cant seem to find a way to do this. Seems I have to use my mouse to open the session manager each time. Mobaxterm I can use Ctrl + Shift + b and I can quickly open and close the session manager.

• How do I upload / download files to a host with Xshell? Mobaxterm has a built in SCP / SFTP manager, Xshell does not. Is rz required on the hosts I am connected to to drag and drop files to send? It looks like I can create separate SFTP sessions to each host... but when I open them it gives me a command line connection. I think I am supposed to literally run put and get commands... is there no built in manager?

• I cant seem to get Ctrl + Alt + v to work with paste. I am using tmux + vim in my terminal. Works fine in Mobaxterm, anyone else having the same issue?

Hoping someone can help who has experience with Xshell. Please do not recommend a different terminal emulator, I am only allowed to use Xterm or putty. I am only looking for advice with the questions above.

I just started my career in Nvidia (Ex-Qualcomm, Ex-Apple), I want to join the Linux community (Open Source) and start my contributions/learnings. Whats the exact steps i need to follow and where and how is this done??

I am running an emulation box with Debian 13, and I use FTP to move files from my unraid server to the box.

I am running this via Ethernet, both systems are on a 1GB ethernet connection. The files are being dropped onto an SSD. FileZilla is only transferring at a rate of 2 MB/s from the Unraid Server to my Debian machine. It has no issues saturating the network when used with other machines on the network. The weirder thing is that if I open the unraid server up as a network drive, I can pull things much faster on the actual machine instead of FTP.

Based on the technical breakdown PaperCut published in its own security bulletin yesterday (Aug 27), plus follow-up reporting from The Hacker News and Help Net Security, here's the architectural impact of the PaperCut NG/MF RCE chain:

CVE-2026-81578 (8.8) is an auth bypass in the admin web UI — under specific conditions, unauthenticated requests can trigger backend admin actions before access validation completes. CVE-2026-82078 (9.4) is worse on its own: the app loads database driver classes by name with no allowlist check. Chain them and you get unauthenticated arbitrary Java bytecode execution on the Application Server.

PaperCut has confirmed customer incidents and just shipped a second emergency patch (Release 2) after Huntress and watchTowr got involved — the first patch apparently wasn't hardened enough. Fixed versions: MF/NG 25.0.12 and 26.0.4.

If your PaperCut server is internet-facing, PaperCut's own guidance is to restrict access to trusted IPs immediately, patch isn't a "next sprint" item here.

https://www.techgines.com/post/papercut-cve-2026-82078-dynamic-class-loading-rce

Anyone running PaperCut in a multi-site or K-12/university deployment — how are you handling the Application Server's public exposure for remote print release? Is anyone actually able to fully firewall it off without breaking mobile/BYOD printing?

[https://github.com/word-sys/puls\](https://github.com/word-sys/puls)

Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.

I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:

- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.

- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.

- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.

- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).

Repository: https://github.com/GiulioSavini/vmware-tools-builder

Feedback, testing across different hypervisor versions, and GitHub stars are welcome.Distro repositories often ship open-vm-tools builds that lag significantly behind upstream releases, delaying kernel/driver fixes, memory balloon enhancements, and CVE patches.I open-sourced vmware-tools-builder to automate building and distributing the latest upstream binaries without polluting the host environment:- Containerized builds: Uses Docker to compile upstream source into standalone .deb and .rpm packages.- Target OS matrix: Ubuntu, Debian, RHEL/Rocky/Alma (8 & 9), Fedora, and openSUSE.- Fleet orchestration: Includes an Ansible role that automates deployment, handles migration from distro-managed packages, and validates the vmtoolsd service state.- Distribution: Packaged and installable directly from Ansible Galaxy (giuliosavini.vmware_tools_builder).Repository: https://github.com/GiulioSavini/vmware-tools-builderFeedback, testing across different hypervisor versions, and GitHub stars are welcome.

While no one can predict the future, I keep on hearing more and more about people getting laid off from IBM, etc--how stable is it for someone with a Red Hat administrator? Or a linux administrator in general?

Currently 34 in help desk tier 2 position. I have my network+, security + and AWS 900 all within this

year. I'm pursuing my EX200 and then my EX294.

A service breaks, someone restarts it and everything works again.

Do you still try to find the root cause, or does it normally get closed unless it happens again?

Not talking about major outages, just the normal smaller incidents. I’ve seen both, but honestly the second one seems far more common.

Based on the technical breakdown published by Gitea's own security advisory and corroborated by CISA's KEV addition (Aug 25) and Help Net Security's incident reporting, here's the architectural impact:

The diffpatch API endpoint installs an executable Git hook from repository-controlled content. An attacker with ordinary write access — reachable via Gitea's default open self-registration — can get RCE as the Gitea OS user. One documented case (via a compromised admin's Habr writeup) went from account creation to a crypto-mining dropper in ~11 seconds. Patched in 1.27.1 (July), but CISA confirmed active exploitation this week regardless.

Background on a related prior Gitea exposure (30K private container registries left open for years) here: [techgines link]

For anyone running self-hosted Gitea in production: what's your actual patch cadence for forge software like this vs. your perimeter devices? Genuinely curious whether teams treat Git servers with the same urgency as firewalls, or if it usually sits in the "get to it" bucket until something like this happens. https://www.techgines.com/post/gitea-cve-2026-60004-diffpatch-rce-exploited

Putting this together after doing it enough times that I finally wrote it down properly. Roughly in order:

1. Disable root SSH login, switch to key-based auth only, change the default port
2. Set up fail2ban (or equivalent) for SSH and any exposed services
3. Firewall — deny by default, allow only what's actually needed
4. Unattended security upgrades, but staged — not blind auto-restart on a production box
5. Audit for and disable unused services/ports
6. CIS benchmark pass for anything customer-facing
7. Basic monitoring so you know if something changes — file integrity, load spikes, new users

Curious what others do differently, especially around automated patching on production — I've seen unattended upgrades cause more downtime than it prevented when it wasn't staged properly. What's your approach?

I have a server (in the logs below it is IP "AAA.BBB.CCC.DDD", domain "my-domain.info") running postfix and postfixadmin. I do have some email accounts being redirected to Gmail -- and I actually had to set up SRS for that (as can be seen in the logs).

I am also using the following blocklists (these are just the relevant lines from main.cf, in smtpd_relay_restrictions:

reject_rbl_client zen.spamhaus.org,
reject_rbl_client relays.visi.com,
reject_rbl_client bl.mailspike.net,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org,
reject_rhsbl_reverse_client dbl.spamhaus.org,

But there is some spam still not being blocked. It is usually detected when the server forwards to the users' Gmail account, as can be seen in the logs:

CB295B315E! 11780 Wed Aug 26 04:11:45 SRS1=NoY3=my-domain.art.br==ekWv=GT=atendes3.com=pedagio-no@my-domain.info

(host gmail-smtp-in.l.google.com[142.251.0.26] said: 550-5.7.1 [AAA.BBB.CCC.DDD 18] Gmail has detected that this message is likely 550-5.7.1 suspicious due to the very low reputation of the sending IP address. 550-5.7.1 To best protect our users from spam, the message has been blocked. 550-5.7.1 For more information, go to 550 5.7.1 https://support.google.com/mail/answer/188131 a1e0cc1a2514c-97cbe44e547si162128241.218 - gsmtp (in reply to end of DATA command))

destination@gmail.com

In this case, the server would redirect some-account@domain.art.br to destination@gmail.com (which is correct, except that it is SPAM and was not detected by those RBLs).

I know I could use spamassassin, but this is a low memory server, no user will offer feedback to help get spamassassin more accurate, and I'm not sure it would actually help. Also, I am not very confident that spamassassin won't come up with false positives, blocking legitimate emails (some of which could be urgent, so quarantine may not be a good idea) -- but I could be wrong.

Before actually installing spamassassin I'd like to know if there are other blocklists I could try.

Thanks!

https://github.com/krisiasty/ghget

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.

It can be as simple as:

$ ghget astral-sh/uv --auto --install --dir ~/.local/bin

selected uv-x86_64-apple-darwin.tar.gz (darwin, amd64, tar.gz archive)
downloaded uv-x86_64-apple-darwin.tar.gz.sha256
downloaded uv-x86_64-apple-darwin.tar.gz
verified uv-x86_64-apple-darwin.tar.gz
installed ~/.local/bin/uv
installed ~/.local/bin/uvx

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.