DEV Community: Ilan Kim

sshole CVE-2026-123158 on Alpine: ssh -V can't tell you if it's patched, so check the package revision and restart sshd

Ilan Kim — Fri, 06 Nov 2026 01:41:44 +0000

On Alpine's backported stable branches, ssh -V cannot tell you whether CVE-2026-123158 (sshole) is patched: on 3.22, the vulnerable 10.0_p1-r10 and the fixed 10.0_p1-r11 both print OpenSSH_10.0p2. Compare the package revision against the Alpine advisory instead, then confirm that the running sshd was actually restarted.

The issue, nicknamed sshole, was disclosed on 2026-11-05 alongside OpenSSH 10.6p2 and Alpine's patches. Plenty of coverage already explains the bug, so this post sticks to the judgment call: is my own sshd on musl exposed, patched, and running the patched binary? I don't run sshd on musl or Alpine myself, so I only verified the check procedure in clean containers on 2026-11-06. I did not reproduce the bypass or attempt any login. A read-only POSIX shell script is included below.

All four conditions must hold for CVE-2026-123158 to apply

The Alpine advisory lists four conditions. If any one is missing, the bypass does not work. The measured column shows the default state of containers with the fixed package on Alpine 3.22.8, 3.23.8 and 3.24.4.

Condition	How to check	Measured on a default install
sshd without PAM	`usepam` line in `sshd -T`	no such line (build without PAM)
`PasswordAuthentication` is on	`sshd -T`	`yes`
An account whose password field is `*`	second field of `/etc/shadow`	`root` only
Another local account with a $5$ or $6$ hash	second field of `/etc/shadow`	none

So a fresh install lacks the fourth condition. The moment someone sets one local password, all four are met. A server with key-only * accounts next to a password account fits this.

The advisory also counts directory users coming through musl-nscd under the third condition. They have no local shadow entry, so /etc/shadow will not show them.

The root cause sits outside OpenSSH, as the OpenSSH release notes say. According to the advisory, musl's crypt() returns * as its error value for an overlong key, and that matches the * stored for an account with no password. The fix commit refuses a match when the stored field is shorter than MIN_PASSWORD_HASH_LEN.

The CVE record scores it CVSS 3.1 8.1. CISA's assessment when I checked on 2026-11-06 was public PoC, not automatable. The record names Alpine as an example, while the Alpine advisory itself did not cite the CVE number on that date. The notices and reports I read mention no exploitation in the wild. That proves nothing, so the log check further down is still worth doing.

These setups are not affected

This list follows the Alpine advisory and the OpenSSH notice:

Containers that don't run sshd. I opened the default alpine:3.22, 3.23 and 3.24 images and none contained sshd.
Servers using openssh-server-pam with UsePAM yes.
Servers with PasswordAuthentication no.
Linux without musl. The notice targets Linux with musl libc and PAM disabled.
Cloud images configured through cloud-init, which writes PasswordAuthentication no.

root is only directly reachable with PermitRootLogin yes, even when its field is *. The defaults I measured were without-password on 3.22 and prohibit-password on 3.23 and 3.24. The advisory adds that another account able to become root through doas still gets there.

Official tiny-cloud images from 3.18.11 through 3.24.3 ship an alpine account with a * field and passwordless doas. They are safe on first boot, and the conditions are met as soon as a $6$ hash exists, for example from a console password.

Same ssh -V, different patch state: the revision decides

Two packages can print the same OpenSSH_10.0p2 and still differ in revision and binary, because Alpine's stable branches backported the fix instead of moving to 10.6p2. The vulnerable packages are already gone from the 3.22, 3.23 and 3.24 repository listings. So I took 10.0_p1-r10 from the alpine-virt-3.22.7 ISO after verifying its signature, and installed it in a container with no network. I never started that sshd and only compared versions:

## Before the fix (Alpine 3.22.7 + package from the ISO)
$ ssh -V
OpenSSH_10.0p2, OpenSSL 3.5.9 29 Sep 2026
$ apk info -v | grep openssh-server-1
openssh-server-10.0_p1-r10
$ sha256sum /usr/sbin/sshd   # first 16 characters
2a78bc6d0cabd9bb  /usr/sbin/sshd

## After the fix (Alpine 3.22.8)
$ ssh -V
OpenSSH_10.0p2, OpenSSL 3.5.9 29 Sep 2026
$ apk info -v | grep openssh-server-1
openssh-server-10.0_p1-r11
$ sha256sum /usr/sbin/sshd   # first 16 characters
54fbd1f03a0aeeb4  /usr/sbin/sshd

The two ssh -V lines are identical to the character. Only r10 versus r11 in apk info -v and the sha256 differ. Note also that the package is named 10.0_p1 while ssh -V prints 10.0p2.

The CVE record lists versions below 10.6p2 as affected, so a plain version string comparison flags the patched r11 as vulnerable. Reading 10.0p2 as "patched" is just as wrong.

These are the fixed versions from the advisory. At or above this version on a branch, the fix is in:

Branch	Fixed `openssh`	Measured `ssh -V`
edge	`10.6_p2-r0`	not measured
3.24	`10.3_p1-r2`	`OpenSSH_10.3p1`
3.23	`10.2_p1-r1`	`OpenSSH_10.2p1`
3.22	`10.0_p1-r11`	`OpenSSH_10.0p2`
3.21	`9.9_p2-r1`	not measured
3.20	`9.7_p1-r6`	not measured
3.19	`9.6_p1-r3`	not measured
3.18	`9.3_p2-r4`	not measured
3.17	`9.1_p1-r7`	not measured
3.16	`9.0_p1-r6`	not measured

No usepam line in sshd -T means a build without PAM

A missing usepam line is not a safe result. The default openssh-server package is built without PAM, and that build's sshd -T prints no usepam line at all. The missing line is the build that meets the condition. Skipping past an empty grep usepam flips your verdict:

$ sshd -T | grep -iE '^(usepam|passwordauthentication) '
passwordauthentication yes

$ sshd.pam -T | grep -iE '^(usepam|passwordauthentication) '   # openssh-server-pam
usepam no
passwordauthentication yes

Installing openssh-server-pam is not enough either. Its default is usepam no, which the advisory lists as affected. That package also ships sshd.pam and no sshd binary.

Install state	Binary	`usepam` in `sshd -T`	Condition
`openssh-server` default	`sshd`	no line	met
`openssh-server` + `UsePAM yes`	`sshd`	no line	met
`openssh-server-pam` default	`sshd.pam`	`no`	met
`openssh-server-pam` + `UsePAM yes`	`sshd.pam`	`yes`	not met

The second row is the trap. Adding UsePAM yes to the default package only printed an Unsupported option UsePAM warning. sshd -t still exited 0 and the usepam line stayed absent, so passing the config test does not mean PAM is on.

One read-only script gives the verdict

The script below prints all of the above in one pass. It writes no files, opens no network connection and never attempts a login. From /etc/shadow it prints only * account names and counts, never a hash. Run it as root on the server itself:

#!/bin/sh
# musl-sshd-check.sh — read-only exposure check for CVE-2026-123158 (OpenSSH + musl, no PAM).
# Reads local package data, sshd -T output, /etc/shadow and /var/log/messages.
# Writes nothing, opens no network connection, never attempts a login and never prints a hash.
# Run as root on the machine itself: sh musl-sshd-check.sh

LOG=/var/log/messages

# Fixed revisions from the Alpine advisory of 2026-11-05.
fixed_for() {
  case "$1" in
    edge) echo 10.6_p2-r0 ;;
    3.24) echo 10.3_p1-r2 ;;
    3.23) echo 10.2_p1-r1 ;;
    3.22) echo 10.0_p1-r11 ;;
    3.21) echo 9.9_p2-r1 ;;
    3.20) echo 9.7_p1-r6 ;;
    3.19) echo 9.6_p1-r3 ;;
    3.18) echo 9.3_p2-r4 ;;
    3.17) echo 9.1_p1-r7 ;;
    3.16) echo 9.0_p1-r6 ;;
    *) echo "" ;;
  esac
}

SSHD=""
for c in sshd sshd.pam sshd.krb5; do
  p=$(command -v "$c" 2>/dev/null) && { SSHD=$p; break; }
done

if [ -z "$SSHD" ]; then
  echo "sshd_binary: none"
  echo "VERDICT: NOT AFFECTED (no OpenSSH sshd installed)"
  exit 0
fi
echo "sshd_binary: $SSHD"

# 1. libc
if ldd "$SSHD" 2>/dev/null | grep -q 'musl'; then libc=musl; else libc=other; fi
echo "libc: $libc"
if [ "$libc" != musl ]; then
  echo "VERDICT: NOT AFFECTED (sshd is not linked against musl)"
  exit 0
fi

# 2. package revision
patched=unknown
if [ -r /etc/alpine-release ] && command -v apk >/dev/null 2>&1; then
  rel=$(cut -d. -f1,2 /etc/alpine-release)
  case "$(cat /etc/alpine-release)" in *_alpha*) rel=edge ;; esac
  pkg=$(apk info -v 2>/dev/null | grep -E '^openssh-server(-pam|-krb5)?-[0-9]' | head -1)
  ver=$(echo "$pkg" | sed -E 's/^openssh-server(-pam|-krb5)?-//')
  fix=$(fixed_for "$rel")
  echo "alpine_branch: $rel"
  echo "package: ${pkg:-not found}"
  echo "fixed_revision: ${fix:-unknown for this branch}"
  if [ -n "$ver" ] && [ -n "$fix" ]; then
    case "$(apk version -t "$ver" "$fix")" in
      '<') patched=no ;;
      *) patched=yes ;;
    esac
  fi
else
  echo "package: not an apk system, compare your vendor's advisory"
fi
echo "patched: $patched"

# 3. effective config. A build without PAM prints no usepam line at all.
cfg=$("$SSHD" -T 2>/dev/null)
if [ -z "$cfg" ]; then
  echo "sshd_T: failed (run as root, host keys required)"
  pwauth=unknown
  usepam=unknown
else
  pwauth=$(echo "$cfg" | awk '$1=="passwordauthentication"{print $2}')
  usepam=$(echo "$cfg" | awk '$1=="usepam"{print $2}')
  [ -n "$usepam" ] || usepam="absent(no PAM in this build)"
  echo "permitrootlogin: $(echo "$cfg" | awk '$1=="permitrootlogin"{print $2}')"
fi
echo "passwordauthentication: $pwauth"
echo "usepam: $usepam"
# sshd -T shows global values only, so a Match block can turn passwords back on.
m=0; pm=0; inc=0
for f in /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf; do
  [ -r "$f" ] || continue
  n=$(grep -ciE '^[[:space:]]*Match[[:space:]]' "$f")
  m=$((m+n))
  n=$(awk '{l=tolower($0)} l ~ /^[ \t]*match[ \t]/{i=1} i && l ~ /^[ \t]*passwordauthentication[ \t=]+"?yes/{c++} END{print c+0}' "$f")
  pm=$((pm+n))
  n=$(grep -iE '^[[:space:]]*Include[[:space:]]' "$f" | grep -vc 'sshd_config\.d/\*\.conf')
  inc=$((inc+n))
done
echo "match_blocks: $m"
echo "match_password_yes: $pm"
echo "other_includes: $inc"

# 4. account state. Names of '*' accounts and counts only.
star_names=""
star=0; bang=0; sha=0
if [ -r /etc/shadow ]; then
  star_names=$(awk -F: '$2=="*"{printf "%s ", $1}' /etc/shadow)
  star=$(awk -F: '$2=="*"{n++} END{print n+0}' /etc/shadow)
  bang=$(awk -F: '$2 ~ /^!/{n++} END{print n+0}' /etc/shadow)
  sha=$(awk -F: '$2 ~ /^\$[56]\$/{n++} END{print n+0}' /etc/shadow)
  echo "shadow_star_accounts: $star ($star_names)"
  echo "shadow_bang_accounts: $bang"
  echo "shadow_sha_hash_accounts: $sha"
else
  echo "shadow: not readable (run as root)"
fi

# Directory users through musl-nscd have no shadow entry, so the counts above miss them.
nscd=no
if apk info -e musl-nscd >/dev/null 2>&1 || [ -S /var/run/nscd/socket ]; then nscd=yes; fi
echo "musl_nscd: $nscd"

# 5. listeners still using a replaced binary. Connections opened before the update
# keep the old binary until they close, and restarting sshd does not end them.
stale=0; old=0; running=0
for d in /proc/[0-9]*; do
  e=$(readlink "$d/exe" 2>/dev/null) || continue
  case "${e% (deleted)}" in
    */sshd|*/sshd.pam|*/sshd.krb5|*/sshd-session*|*/sshd-auth*) running=$((running+1)) ;;
    *) continue ;;
  esac
  case "$e" in *" (deleted)") ;; *) continue ;; esac
  case "$(tr '\0' ' ' < "$d/cmdline" 2>/dev/null)" in
    *"[listener]"*) stale=$((stale+1)) ;;
    *) old=$((old+1)) ;;
  esac
done
echo "sshd_processes: $running"
echo "listeners_on_replaced_binary: $stale"
echo "connections_on_replaced_binary: $old"

# 6. password logins for accounts that have no password
hits=0
if [ -r "$LOG" ]; then
  for a in $star_names; do
    n=$(grep -c "Accepted password for $a " "$LOG")
    [ "$n" -gt 0 ] || continue
    if [ "$usepam" = yes ]; then
      echo "trace_note: $n 'Accepted password for $a' in $LOG (UsePAM yes, check how this user authenticates)"
    else
      echo "trace: $n 'Accepted password for $a' in $LOG"
      hits=$((hits+n))
    fi
  done
  if [ "$nscd" = yes ]; then
    for u in $(grep -o 'Accepted password for [^ ]*' "$LOG" | awk '{print $4}' | sort -u); do
      grep -q "^$u:" /etc/shadow 2>/dev/null && continue
      n=$(grep -c "Accepted password for $u " "$LOG")
      echo "trace_note: $n 'Accepted password for $u' in $LOG (no shadow entry, check how this user authenticates)"
    done
  fi
  echo "trace_hits: $hits"
else
  echo "trace_hits: $LOG not readable or absent, check your log destination"
fi

# Verdict
pw_open=no
if [ "$pwauth" != no ] || [ "$pm" -gt 0 ]; then pw_open=yes
elif [ "$m" -gt 0 ] || [ "$inc" -gt 0 ]; then pw_open=unknown
fi
conditions=no
if [ "$pw_open" != no ] && [ "$usepam" != yes ]; then
  if [ ! -r /etc/shadow ]; then conditions=unknown
  elif [ "$sha" -gt 0 ] && [ "$star" -gt 0 ] && [ "$pw_open" = yes ]; then conditions=yes
  elif [ "$sha" -gt 0 ] && { [ "$star" -gt 0 ] || [ "$nscd" = yes ]; }; then conditions=unknown
  fi
fi
if [ "$hits" -gt 0 ]; then
  echo "VERDICT: INVESTIGATE (password login recorded for an account with no password)"
elif [ "$patched" = no ] && [ "$conditions" = yes ]; then
  echo "VERDICT: EXPOSED (old revision, all conditions met)"
elif [ "$patched" = no ] && [ "$conditions" = unknown ]; then
  echo "VERDICT: UPDATE NEEDED (old revision, conditions could not be confirmed)"
elif [ "$patched" = no ]; then
  echo "VERDICT: UPDATE NEEDED (old revision, conditions not all met now)"
elif [ "$patched" = yes ] && [ "$stale" -gt 0 ]; then
  echo "VERDICT: RESTART REQUIRED (package fixed, running listener is the old binary)"
elif [ "$patched" = yes ]; then
  echo "VERDICT: PATCHED"
else
  echo "VERDICT: UNKNOWN (compare your vendor's advisory, conditions met: $conditions)"
fi

This is the result on a default fixed 3.22.8 install. root is *, but the revision is fixed, so it ends in PATCHED:

sshd_binary: /usr/sbin/sshd
libc: musl
alpine_branch: 3.22
package: openssh-server-10.0_p1-r11
fixed_revision: 10.0_p1-r11
patched: yes
permitrootlogin: without-password
passwordauthentication: yes
usepam: absent(no PAM in this build)
match_blocks: 0
match_password_yes: 0
other_includes: 0
shadow_star_accounts: 1 (root )
shadow_bang_accounts: 16
shadow_sha_hash_accounts: 0
musl_nscd: no
sshd_processes: 0
listeners_on_replaced_binary: 0
connections_on_replaced_binary: 0
trace_hits: /var/log/messages not readable or absent, check your log destination
VERDICT: PATCHED

There are seven possible verdicts. All test environments in the table were containers with no network.

`VERDICT`	Meaning	State I tested
`EXPOSED`	old revision, conditions met	r10 + one hash account, `sshd -T` failing
`UPDATE NEEDED`	old revision, conditions not met now or not confirmed	r10 + no hash account, `sshd -T` failing; the "not confirmed" paths are branch tests only
`RESTART REQUIRED`	package fixed, running sshd is the old file	fixed sshd started, then the file replaced
`PATCHED`	at or above the fixed revision	fixed package defaults
`INVESTIGATE`	password login recorded for a `*` account	one synthetic log line
`NOT AFFECTED`	no sshd, or not musl	default image without sshd
`UNKNOWN`	fixed version not known	release changed to a branch outside the table

The two r10 rows are branch tests only. To avoid running the r10 sshd I masked it with another file, so passwordauthentication printed unknown, which the script treats as on. On a real server, run it as root so the value is read properly. I did not exercise the path for an sshd that isn't linked against musl.

EXPOSED is deliberately broad. permitrootlogin is printed but not used in the verdict, so a server whose only * account is root with direct login blocked can still show EXPOSED.

Even with a global no, a PasswordAuthentication yes inside a Match block counts as open, and match_password_yes is the number of those lines. I tested this by reading the fixed sshd's real config while faking only the apk response as r10, and it printed EXPOSED. The script reads only /etc/ssh/sshd_config and /etc/ssh/sshd_config.d/*.conf.

It does not follow conditional Include lines. So with a global no plus a Match block or an Include of another path, it won't claim the conditions are unmet. It ends in conditions could not be confirmed, and you check per-account values with sshd -T -C as shown below.

The script cannot count directory users. If musl_nscd: yes and there is no local * account, it also ends in conditions could not be confirmed, and you need to check the directory accounts yourself. The same wording appears when it can't read /etc/shadow because it isn't root.

Check scripts and reproduction code are circulating online, and I ran none of them. Read any script before running it as root on a server, and that includes this one.

After the package upgrade, restart sshd or you aren't done

Replacing the package does not replace the running daemon. With a fixed sshd running, I swapped the file underneath it and the process kept holding the deleted old file. To avoid starting the vulnerable revision, this test reinstalled the same revision to replace only the file:

$ readlink /proc/18/exe      # before replacing
/usr/sbin/sshd
$ apk fix -r openssh-server
$ readlink /proc/18/exe      # package replaced, not restarted
/usr/sbin/sshd (deleted)
$ readlink /proc/38/exe      # after restart
/usr/sbin/sshd

The order below follows the Alpine advisory:

Keep one SSH session open while you upgrade the package.

   apk upgrade -U -a

Restart sshd.

   rc-service sshd restart

Confirm key login works from a new session, then close the old one.
Run the check script again and confirm RESTART REQUIRED is gone.
Rebuild any container image with sshd baked in. Per the advisory, images built from 3.21.10, 3.22.8, 3.23.8 and 3.24.4 onward contain the fix.

RESTART REQUIRED looks at the listener only. Connections opened before the update, like the session you kept in step 1, may hold the old file, but they are counted separately as connections_on_replaced_binary and don't affect the verdict. The Alpine OpenRC script only ends connections at system shutdown, so a restart won't lower that number. Closing those sessions will.

If you can't upgrade yet, block it with PasswordAuthentication no

The advisory says either the update or this setting closes the hole. Confirm key login works first, or you will lock yourself out. A drop-in line alone leaves any Match override in place. The advisory's full command also rewrites lines inside Match blocks in sshd_config:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

Alpine reads the drop-in directory from 3.19 on, and earlier releases ignore it. The sed keeps the original as sshd_config.bak. It only touches sshd_config, so a Match inside a drop-in file has to be fixed by hand.

sshd -T shows global values only, so the final no alone isn't proof. I added a Match User keyonly block in fixed 3.22 and 3.24 containers, and both gave the same result:

# drop-in only
sshd -T: passwordauthentication no
sshd -T -C user=keyonly: passwordauthentication yes
# after the advisory's sed
sshd -T: passwordauthentication no
sshd -T -C user=keyonly: passwordauthentication no

On a server that uses Match, query the value for a specific account like this. With Match Address, replace addr with a real client address too:

sshd -T -C user=<account>,host=localhost,addr=127.0.0.1 | grep ^passwordauthentication

Check Accepted password for lines first to see if you were hit

An Accepted password for line on an account with no password should be treated as suspected compromise, because that account should not be able to log in with a password. This is also the detection method the advisory gives:

grep "Accepted password for" /var/log/messages

Compare the account names with shadow_star_accounts from the script. The script does the same comparison and prints INVESTIGATE on a match. I tested that path with one synthetic log line only and have never seen a real compromise log.

trace_note is a reference line. On UsePAM yes servers, or for directory users with no shadow entry, PAM may have handled the login normally, so those records don't become INVESTIGATE. Check how that user actually authenticates.

If you find such a record, or no logs survive, continue with:

doas usage records
recently created users and files
changes to authorized_keys

If your server logs somewhere other than /var/log/messages, look there, since the script reads only that file. The advisory says to treat the machine as compromised if you can't rule out a login.

Takeaways

On Alpine, judge CVE-2026-123158 by the package revision rather than ssh -V, then confirm the listener restarted. If you use PasswordAuthentication no as a stopgap, check Match overrides with sshd -T -C.

Unverified

Actual bypass behavior. I did not reproduce the bypass or attempt a long-password login. The description comes from the OpenSSH notice, the CVE record and the Alpine advisory.

Whether the fix blocks it. I did not test that r11 actually stops the bypass. The patched verdict relies only on the advisory's version table.

Exploitation in the wild. As of 2026-11-06 the notices and reports I read mention none. That doesn't mean there was none.

OpenWrt, Buildroot, Yocto. These come up because they use musl, but I found no official notice, and I did not check OpenWrt's default SSH server setup. The script is built around Alpine packages.

Cloud images. Statements about tiny-cloud and cloud-init images are quoted from the advisory. I did not boot a real cloud image.

OpenRC restart path. OpenRC doesn't run in the containers, so I did not run rc-service sshd restart. I stopped and started the process directly and saw (deleted) disappear.

The vulnerable revision's sshd. r10 was installed but its sshd was never run, so I have no sshd -T output from it.

Vulnerable revisions outside 3.22. My before/after comparison covers 3.22's r10 only. I did not confirm the same ssh -V pattern on other branches with vulnerable packages.

Drop-ins on 3.18 and older. I confirmed drop-ins on 3.22 and 3.24 only. The 3.19 boundary is quoted from the advisory, and older releases need sshd_config edited directly.

Existing connection handling. Without logging in I could not test a real connection. I saw the branch only with a fake process, a busybox copy started under the name sshd-session. The [listener] title that identifies the listener was confirmed on 3.22, 3.23 and 3.24 only.

musl-nscd branch. I tested this branch by faking the apk response without installing musl-nscd, and never saw a real directory user setup.

Public check scripts. I did not run any external check script or reproduction code.

NVD assessment. I could not confirm the content of the NVD page.

Changelog

Version	Description
1.0	2026-11-06 first English version, based on Korean version 1.0 (container measurements on Alpine 3.22.8, 3.23.8, 3.24.4, version comparison with the vulnerable `r10`, read-only check script)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

NIKKE PC launcher hack: was my PC infected? k2f_chan in debug.log, 4 traces to check, accounts to rotate (2026-11-04)

Ilan Kim — Thu, 05 Nov 2026 00:35:45 +0000

If the NIKKE PC launcher's debug.log contains k2f_chan, the malicious agent ran on that PC, and the official notice of 2026-11-05 also treats that line as a sign it may have run. Deleting the files is not enough: change every password, session and API key that was on that PC, and do it from a different device.

This is for anyone who has started the NIKKE: Goddess of Victory PC launcher recently and wants to judge their own machine. My Windows PC was actually infected on the evening of 2026-11-03, and it held Claude Code and Codex settings and development API keys. I checked it read-only on 2026-11-04, and the PowerShell script I wrote to look for the same traces is below. Two official notices came out the next day, so this version includes them too. All times are KST (UTC+9).

k2f_chan in NIKKE's debug.log means your PC was infected

My debug.log had a burst of infection markers at 19:25 on November 3. Here is what my read-only check script printed. For the lines that contain the computer name or a UUID, I kept only the line number and time:

== <drive>:\NIKKE\launcher\intl_service\debug.log
size=21872758  LastWriteTime=2026-11-03 20:26:05 (local)
total_lines=120580
-- 'k2f_chan' hits=1
   line 120569: [1103/192510.949:INFO:CONSOLE(1)] "k2f_chan registered", source:  (1)
-- 'lua downloaded to' hits=1
   line 120567  ts=1103/192510.909
-- 'adopted' hits=1
   line 120570  ts=1103/192511.005
-- 'agent started as' hits=1
   line 120571  ts=1103/192511.007

The image is not the raw log. It redraws the check result in line order. Only the k2f_chan registered line is verbatim; the others are the marker strings listed in the public analysis gist.

The prefix [1103/192510.949] means November 3, 19:25:10, in the PC's local time. The last line of the file, 1103/202605, matched the file's last-write time of 20:26:05 KST. The gist takes even a single k2f_chan line to mean the agent ran. By the official manual-check notice, a k2f_chan registered line means it may have run.

The log is at Launcher\intl_service\debug.log inside your NIKKE install folder. You can open it in Notepad and search, as the notice suggests, but mine was 21.9 MB. In PowerShell, one line does it; change the path to your own install folder:

Select-String -Path "D:\NIKKE\Launcher\intl_service\debug.log" -Pattern "k2f_chan" -SimpleMatch

If even one line comes back, the PC was infected. If nothing comes back, this log shows no sign the agent ran. The notice still says that doesn't fully rule out risk and recommends a full antivirus scan. If you deleted or reinstalled the NIKKE folder, this log is gone with it.

Running the launcher in that window doesn't mean you were infected

Since September 27, my log has launcher records on 18 days. k2f_chan appears on only one of them, November 3. Even after the official start of distribution, there were 4 days with launcher records and no load.

Period	Days with launcher records	`k2f_chan`	Official timeline
9/28 to 10/29	13	0	after tampering, before distribution started
10/30 to 11/2	4	0	after distribution started (10/30 03:52)
11/3	1	1 (19:25:10)	after distribution started

Zero hits up to October 29 is expected, because by the notice that was before distribution began. Why the four days from the evening of October 30 through November 2 are empty, the log alone can't tell. Judge by your own log, not by the dates.

The second launcher on the same PC, NIKKE_GOOGLE, has no records for this period; its log ends on June 13.

The official notice targets anyone who started the Windows PC launcher at least once after 15:41 on September 27. The notice says the mobile version is not affected. If you only play on mobile, you don't need to check.

The gist says Linux via Proton and the Steam Deck are affected too, except that the Chrome-side traces don't appear under Proton. Neither the notice nor the gist covers the Microsoft Store version or macOS.

The NIKKE PC launcher hack started with tampering on September 27

According to the official notice of 2026-11-05, the incident began on September 27. That morning a third party took over insightjs.com, a domain used by some game services. That afternoon, four scripts on the official CDN that the launcher downloads were tampered with.

Distribution of the malware to players' PCs started at 03:52 on October 30, through the tampered scripts. The table below puts the gist's observations into the notice's timeline. I converted the gist's GMT times to KST. Only the 11-03 19:25 row is my own measurement.

Time (KST)	Event	Source
09-27 10:59	Third party takes over `insightjs.com`, a domain used by some game services	notice
09-27 15:41 to 15:42	Four official CDN scripts the launcher downloads are tampered with (`aegis-fix.min.js`, `images.7fec4c32.js`, `FeedList.feb647c9.js`, `vue-bucket.min.js`)	notice; file names from the gist
10-24 01:40	First report of the agent running	gist
10-29 00:46	Only the origin server of `FeedList.feb647c9.js` gets the clean file; some CDNs keep serving the tampered one	gist
10-30 03:52	Malware distribution to players' PCs starts through the tampered scripts	notice
11-03 19:25	`k2f_chan registered` on my PC	my measurement
11-04 around 00:00	Anomaly detected, investigation starts	notice
11-04 01:11	First public warning on a NIKKE community Discord	gist
11-04 02:04 to 02:23	Three abnormal files replaced (first pass)	notice (the gist says until 02:21)
11-04 03:31	Attacker server stops responding	gist
11-04 07:26	Last sighting of two CDN nodes serving the tampered `FeedList`	gist
11-04 12:09	CDN cache refresh for the remaining file completed, then rolled out to nodes one by one (second pass)	notice
11-05 08:00	Official PC client starts automatic malware scan	notice

The gist's first report of the agent running (10-24 01:40) is six days earlier than the notice's start of distribution (10-30 03:52). Neither source explains the gap, so the table keeps both times side by side with their sources.

The two notices went up on 2026-11-05 on the official Korean NIKKE site's notice board (Korean). One covers what happened and the follow-up measures; the other is a manual-check guide. I read them at 08:35 that day. I didn't check whether the global site carries English versions, so everything I attribute to "the notice" here is my summary of the Korean posts, not a quote.

For prevention, the notice lists stronger monitoring, integrity checks on external resources, and least privilege. Before the notices, on November 4, both Shift Up and the publisher Level Infinite only told Korean press they were looking into it (Yonhap, TechM, both Korean). Inven Global covered it in English on November 3, before any statement.

Reports differ slightly on the number of tampered files and the start date, so this post follows only the notices and the gist. The gist also lists the attacker's server addresses and an IP blocklist, but I left them out of this post.

What the gist says the agent collects is broad. It includes passwords and cookies saved in browsers and the NIKKE login saved in the launcher. On the developer side it looks at SSH keys, API tokens, .env files and cloud credentials. On top of that come 28 wallet extensions, screenshots of every monitor, and remote command execution.

A read-only script checks all four traces at once

Besides debug.log, the official notice names four traces to delete. The script below reads those four plus the log, and that's all. It deletes nothing, changes nothing, and connects to nothing.

Trace	Location	Notes
Launcher web cache	`%APPDATA%\nikke_launcher\tbs_cache`	Survives deleting the NIKKE folder; `k2f.agent` in its leveldb
Chrome persistence DLL	`%LOCALAPPDATA%\Google\Chrome\User Data\PlatformExperienceHelper\<64 hex chars>\platform_experience_helper.dll`	The `PlatformExperienceHelper` folder itself is a normal part of Chrome
COM hijack key	`HKCU\Software\Classes\CLSID\{E77CC89B-7401-4C04-8CED-149DB35ADD04}`	Don't delete the same ID under HKLM
Launcher download log	`Launcher\log\tinyget\tinyget.<date>-<time>.log`	Only the file that is exactly 205,135 bytes (about 200 KB), per the notice
Temp files	`%TEMP%\k2f-bcreds-`, `%TEMP%\k2f_screen_.jpg`	Gist indicators outside the four; deleted right after use, so absence proves nothing

Paste the script into Notepad and save it as nikke-check.ps1. Open PowerShell in that folder and run it like this. No admin rights are needed, and -ExecutionPolicy Bypass applies only to this one run:

powershell -NoProfile -ExecutionPolicy Bypass -File .\nikke-check.ps1

Anything the script can't read is printed as [ERROR], and the result line then says the check is incomplete. If it can't find your install folder, pass it with -NikkeDir, pointing at the folder that contains Launcher. The script is ASCII-only with English output, because PowerShell 5.1 reads a script without a BOM in the system code page. Here is the full script:

# nikke-check.ps1 - NIKKE PC launcher compromise (2026-10~11) read-only check
# Reads files and registry only. Deletes nothing, changes nothing, connects to nothing.
# Output is printed to this window only. Indicators follow the public analysis gist
# "NIKKE PC launcher compromise (November 2026)" by MotherSphere and the official
# NIKKE notices of 2026-11-05 (tinyget file size).
# Usage (normal PowerShell, no admin needed):
#   powershell -NoProfile -ExecutionPolicy Bypass -File .\nikke-check.ps1
#   powershell -NoProfile -ExecutionPolicy Bypass -File .\nikke-check.ps1 -NikkeDir "D:\Games\NIKKE"
param([string]$NikkeDir = '')
$ErrorActionPreference = 'SilentlyContinue'
$script:found = 0; $script:errors = 0
function Hit([string]$label, [string[]]$detail) { "[FOUND] $label"; foreach ($d in $detail) { if ($d) { "        $d" } }; $script:found++ }
function Ok([string]$label) { "[OK]    $label" }
function Note([string]$label) { "[NOTE]  $label" }
function Err([string]$label) { "[ERROR] $label"; $script:errors++ }

"NIKKE PC launcher check (read-only)  " + (Get-Date -Format 'yyyy-MM-dd HH:mm')
""

# 1. debug.log : k2f_chan = the malicious agent ran on this PC
$dirs = @()
if ($NikkeDir) { $dirs += $NikkeDir; $dirs += (Join-Path $NikkeDir 'Launcher') }
$un = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
      'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
      'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*'
$dirs += Get-ItemProperty $un | Where-Object { $_.DisplayName -match 'NIKKE' -and $_.UninstallString } |
  ForEach-Object { Split-Path ($_.UninstallString -replace '^"([^"]+)".*$', '$1') -Parent }
foreach ($r in (Get-PSDrive -PSProvider FileSystem).Root) { $dirs += (Join-Path $r 'NIKKE\Launcher') }
$logs = @($dirs | ForEach-Object { Join-Path $_ 'intl_service\debug.log' } |
  Where-Object { Test-Path -LiteralPath $_ } | ForEach-Object { (Resolve-Path -LiteralPath $_).Path } | Sort-Object -Unique)
if ($logs.Count -eq 0) { Note "debug.log not found. Re-run with -NikkeDir pointing to the folder that holds Launcher." }
foreach ($log in $logs) {
  Note ("debug.log: $log  (last write " + (Get-Item -LiteralPath $log).LastWriteTime.ToString('yyyy-MM-dd HH:mm') + ")")
  try {
    $h = @(Select-String -LiteralPath $log -Pattern 'k2f_chan' -SimpleMatch -ErrorAction Stop)
    if ($h.Count) {
      Hit "debug.log: k2f_chan x$($h.Count)" ($h | ForEach-Object { "line $($_.LineNumber): " + $_.Line.Substring(0, [Math]::Min(55, $_.Line.Length)) })
    } else { Ok "debug.log: no k2f_chan" }
    foreach ($p in 'lua downloaded to', 'agent started as') {
      $c = @(Select-String -LiteralPath $log -Pattern $p -SimpleMatch -ErrorAction Stop).Count
      if ($c) { Hit "debug.log: '$p' x$c" }
    }
  } catch { Err "debug.log could not be read: $log ($($_.Exception.Message))" }
}

# 2. Launcher\log\tinyget : tinyget.<date>-<time>.log of exactly 205,135 bytes (official notice, 2026-11-05)
#    Name, size and time only - the file content is not read.
$tg = @($dirs | ForEach-Object { Join-Path $_ 'log\tinyget' } |
  Where-Object { Test-Path -LiteralPath $_ } | ForEach-Object { (Resolve-Path -LiteralPath $_).Path } | Sort-Object -Unique)
if ($tg.Count -eq 0) { Note "Launcher\log\tinyget not found (same folders as debug.log were checked)" }
foreach ($d in $tg) {
  try {
    $m = @(Get-ChildItem -LiteralPath $d -File -Force -ErrorAction Stop |
      Where-Object { $_.Length -eq 205135 -and $_.Name -match '^tinyget\.\d{8}-\d{6}.*\.log$' })
    if ($m.Count) { Hit "tinyget: 205,135-byte log x$($m.Count) in $d" ($m | ForEach-Object { $_.Name + '  (last write ' + $_.LastWriteTime.ToString('yyyy-MM-dd HH:mm') + ')' }) }
    else { Ok "tinyget: no 205,135-byte tinyget.<date>-<time>.log in $d" }
  } catch { Err "tinyget folder could not be listed: $d ($($_.Exception.Message))" }
}

# 3. launcher web cache (survives deleting the NIKKE folder)
$tbs = Join-Path $env:APPDATA 'nikke_launcher\tbs_cache'
if (Test-Path -LiteralPath $tbs) {
  $c = 0; $unread = 0; $ldb = Join-Path $tbs 'Local Storage\leveldb'; $files = @()
  if (Test-Path -LiteralPath $ldb) {
    try { $files = @(Get-ChildItem -LiteralPath $ldb -File -Force -ErrorAction Stop) }
    catch { Err "tbs_cache leveldb could not be listed: $ldb ($($_.Exception.Message))" }
  }
  foreach ($f in $files) {
    try { $c += @(Select-String -LiteralPath $f.FullName -Pattern 'k2f.agent' -SimpleMatch -ErrorAction Stop).Count } catch { $unread++ }
  }
  if ($c) { Hit "tbs_cache leveldb: k2f.agent x$c" $tbs }
  else { Note "tbs_cache exists, no k2f.agent string (compressed .ldb can hide it). Delete it before the next launch: $tbs" }
  if ($unread) { Err "tbs_cache leveldb: $unread file(s) could not be read (close the launcher and run again)" }
} else { Ok "tbs_cache: not present" }

# 4. Chrome persistence: 64-hex folder holding platform_experience_helper.dll
$peh = Join-Path $env:LOCALAPPDATA 'Google\Chrome\User Data\PlatformExperienceHelper'
try {
  $bad = @(if (Test-Path -LiteralPath $peh) { Get-ChildItem -LiteralPath $peh -Directory -Force -ErrorAction Stop | Where-Object {
    $_.Name -match '^[0-9a-fA-F]{64}$' -and (Test-Path -LiteralPath (Join-Path $_.FullName 'platform_experience_helper.dll')) } })
  if ($bad.Count) { Hit "Chrome PlatformExperienceHelper: 64-hex folder with the DLL x$($bad.Count)" ($bad | ForEach-Object { $_.FullName }) }
  else { Ok "Chrome PlatformExperienceHelper: no 64-hex folder with the DLL (the folder itself is normal)" }
} catch { Err "Chrome PlatformExperienceHelper could not be listed: $peh ($($_.Exception.Message))" }

# 5. COM hijack key (HKCU only - an HKLM key with the same id, if present, is normal)
$id = '{E77CC89B-7401-4C04-8CED-149DB35ADD04}'
if (Test-Path "HKCU:\Software\Classes\CLSID\$id") {
  Hit "HKCU CLSID $id exists" ("InprocServer32 = " + (Get-ItemProperty "HKCU:\Software\Classes\CLSID\$id\InprocServer32").'(default)')
} else { Ok "HKCU CLSID $id : not present" }
Note ("HKLM CLSID $id : " + $(if (Test-Path "HKLM:\SOFTWARE\Classes\CLSID\$id") { 'present' } else { 'absent' }) + " (normal either way - do not delete)")

# 6. other HKCU COM entries loading a DLL from AppData
try { $keys = @(Get-ChildItem 'HKCU:\Software\Classes\CLSID' -ErrorAction Stop) }
catch { $keys = @(); Err "HKCU CLSID list could not be read ($($_.Exception.Message))" }
foreach ($k in $keys) {
  $v = (Get-ItemProperty (Join-Path $k.PSPath 'InprocServer32')).'(default)'
  if ($v -match 'PlatformExperienceHelper') { Hit "HKCU CLSID $($k.PSChildName) loads $v" }
  elseif ($v -match 'AppData') { Note "HKCU CLSID $($k.PSChildName) loads a DLL from AppData (check the vendor): $v" }
}

# 7. leftovers in %TEMP% (the agent deletes them right after use - absence proves nothing)
try {
  $t = @(Get-ChildItem -LiteralPath $env:TEMP -Force -ErrorAction Stop | Where-Object { $_.Name -cmatch '^k2f[-_]' })
  if ($t.Count) { Hit "%TEMP%: k2f-* / k2f_* x$($t.Count)" ($t | ForEach-Object { $_.Name }) } else { Ok "%TEMP%: no k2f-* / k2f_* items" }
} catch { Err "%TEMP% could not be listed: $env:TEMP ($($_.Exception.Message))" }

# 8. DLL loaded right now
$p = @(Get-Process | Where-Object { $_.Modules.ModuleName -contains 'platform_experience_helper.dll' })
if ($p.Count) { Hit "platform_experience_helper.dll loaded in: $(($p | ForEach-Object { $_.ProcessName + '(' + $_.Id + ')' }) -join ', ')" }
else { Ok "platform_experience_helper.dll: not loaded in any visible process" }

""
if ($script:found) { "RESULT: $($script:found) indicator(s) found. Follow the removal order, then change passwords from another device." }
elseif ($script:errors) { "RESULT: check incomplete - $($script:errors) item(s) could not be read. Close the launcher and run again." }
else { "RESULT: no indicators found by this script. This is not proof of a clean PC." }
if ($script:found -and $script:errors) { "        ($($script:errors) item(s) could not be read - see [ERROR] lines)" }

The screenshot is from the 2026-11-04 run, so it has no tinyget line; I added that check in the 2026-11-05 revision.

On my PC only debug.log produced hits, three of them. The launcher cache, the Chrome DLL and the HKCU key were all absent. I had already deleted tbs_cache myself before the check. For the other two, all I can say is that they weren't there when I checked. This PC had no Chrome installed, but the gist says the DLL and key can appear even without Chrome.

I listed the tinyget folder separately during the 11-04 check. The lua downloaded to line at 19:25:10 on November 3 pointed to tinyget.20261103-192508-898.log. No file with that name was left when I checked.

The tinyget logs that were left were 69,902 bytes for November 1 and 2 and 90,382 bytes for November 3. There was no 205,135-byte file, the size the notice names, on my PC. I couldn't confirm whether the downloaded file was that file, or why it disappeared.

The HKLM result differed from the gist. The gist says the same CLSID exists under HKLM as a normal key pointing to wpc.dll on every Windows install. On my Windows 11 (build 26300) that key didn't exist at all. Either way, leave HKLM alone.

A loose search for k2f in %TEMP% gives false positives. On my PC it matched five folders, all random names that happened to contain K2F, like <tool>-K2FRwQ. That's why the script only counts names starting with k2f- or k2f_.

I also went through autostart entries separately. Run keys, the Startup folder and scheduled tasks had zero suspicious items, and so did HKCU COM entries loading a DLL from AppData. Defender's detection history was empty too, which means nothing here: Defender was off and a third-party antivirus was registered on that PC.

If you're infected, remove things in this order

The easiest route is the official PC client's automatic scan. According to the notice, from 08:00 on 2026-11-05 the client finds and removes the malware itself. Close every browser, including Chrome, then start the client.

If it finds something, a popup asks whether to delete the logs, the DLL and the registry entries, and agreeing deletes them. If nothing is found, the game just starts with no popup. The notice also says that if a browser wasn't fully closed and the DLL stays behind, it no longer runs.

The manual-check notice calls this feature the ACE security feature. The gist had advised not to start the launcher until a fix was confirmed. Per the notice, replacement of the tampered files finished at 12:09 on November 4 and then rolled out to the CDN nodes one by one.

To remove things by hand, follow the notice's order. First disconnect from the internet and fully quit NIKKE, its launcher and Chrome. Check the system tray icons too, and don't start the launcher again until you're done.

The DLL is locked while it's loaded and can't be deleted, which is why the order matters:

In Registry Editor, delete {E77CC89B-7401-4C04-8CED-149DB35ADD04} under HKEY_CURRENT_USER\Software\Classes\CLSID. The same name exists under other paths too, so delete it only at this path.
Restart Windows. The gist reports that the DLL stays locked even after closing every Chrome window.
Inside PlatformExperienceHelper, delete only the folder whose name is 64 hex characters and that contains platform_experience_helper.dll. Leave the PlatformExperienceHelper folder itself. If no such folder exists now, the notice reads that as the DLL not being installed.
In Launcher\log\tinyget, delete the file that is 205,135 bytes and named like tinyget.<date>-<time>.log.
Delete the whole %APPDATA%\nikke_launcher\tbs_cache folder.
Update your antivirus and run a full scan, then also run a Microsoft Defender Offline scan from Windows Security.

A clean antivirus result doesn't prove removal. The gist says reinstalling Windows is the safest option.

Under Proton, tbs_cache lives inside the Proton prefix. The Chrome DLL and the registry key don't apply on Linux.

Deleting the traces doesn't bring back leaked accounts and API keys

Removing the traces doesn't undo what has already left the PC. So do the account work on a different, clean device, not the infected PC. Here is the gist's recommended order as a table:

Order	What	Why	What to do
1	NIKKE and Level Infinite account	The login saved in the launcher is collected	Change the password, turn on 2FA
2	Email	Recovery path for your other accounts	Change the password, turn on 2FA
3	Discord, Google, Steam, GitHub sessions	A cookie alone logs in without the password	Log out of all sessions
4	Banking, passwords saved in browsers	Saved passwords from Chrome, Edge, Firefox and others are collected	Change the passwords for saved sites
5	API tokens, SSH keys, cloud credentials	Developer credential files and `.env` are collected	Revoke the old keys and issue new ones
6	Crypto wallets	28 Chrome wallet extensions	Move funds to a new wallet with a new seed phrase

Session logout is the step people skip. Changing a password can leave sessions opened with stolen cookies alive. Hit each service's "log out of all devices" option once.

The notice's two account-protection steps overlap with this table. Changing the passwords of accounts used on that PC covers rows 1 to 4. Revoking and reissuing API keys and access tokens used or stored on that PC is row 5. The notice adds that you should do this from an unaffected device or from a PC that has finished the check.

For damage to accounts outside the game, or financial loss, the notice says to contact official customer support.

Here is what I actually did. I deleted tbs_cache before the check and scanned with Norton 360, which found nothing. I changed passwords and logged out of every session. I revoked my Claude and OpenAI API keys and my GitHub token. Then I formatted Windows. That was the price of not keeping my gaming PC and my work PC separate.

Community-made scanners are going around too. I didn't run any; I looked for the same traces with the read-only script in this post.

Takeaways

If debug.log has a k2f_chan registered line, treat the PC as infected: remove the traces in the notice's order or let the official client's scan do it, then rotate passwords, sessions and API keys from another device. Launching in that window doesn't mean infection by itself, so judge by your own log, and keep in mind that a clean scan doesn't prove removal.

Unverified

The traces before removal: the only trace I deleted was tbs_cache, and I didn't keep a screenshot. I couldn't confirm whether it held k2f.agent, or whether the Chrome DLL and HKCU key existed before. My account of what I did relies on memory. The tinyget.20261103-192508-898.log file that debug.log pointed to was also gone at check time. I don't know whether it was the notice's 205,135-byte file, or when and why it disappeared.

Whether anything actually leaked: no unusual account activity so far is not proof that nothing leaked. The PC-side logs can't show what the agent took. The gist also says remote commands leave nothing in the launcher logs.

Why the agent didn't load on some days after distribution began: zero hits through October 29 is explained by the notice's start of distribution. From that start (03:52 on October 30) through November 2, there was still no k2f_chan for four days. I don't know whether that was the CDN cache or some other condition.

Microsoft Store, Google Play Games and macOS: the notice covers the Windows PC launcher and says mobile is unaffected. Neither the notice nor the gist covers the other versions. The notice's example paths include NIKKE_GOOGLE, but that alone doesn't settle whether the Google Play Games version is affected. I only checked the PC launcher version.

The script on Steam and Proton: the script finds the install folder from the uninstall registry entries and also tries NIKKE\Launcher on every drive. I haven't run it against a Steam install path or under Proton.

Whether the removal order works: the removal order here matches the notice's manual-check steps. But my PC had no HKCU key, no Chrome DLL and no 205,135-byte tinyget file at check time, so I couldn't walk through the steps myself.

The official client's automatic scan: the scan has run since 08:00 on November 5, but I had already formatted that PC and couldn't try it. The detection conditions and popup behavior come only from the notice.

The script's tinyget size check: the 205,135-byte check, added on 2026-11-05, is built only from the size and name pattern in the notice. It has never run on Windows, and I haven't confirmed that it fires on an infected PC.

Other Level Infinite games: other games that use the same launcher components have been mentioned as possibly affected. This post checks only the NIKKE launcher.

Community scanner results: I didn't run the community scanners, so I couldn't compare their results with this script's.

Changelog

Version	Description
1.0	2026-11-05 first English version, based on Korean version 1.1 (read-only check of my PC on 2026-11-04: one k2f_chan line in debug.log, no other traces; two official notices of 2026-11-05: timeline, tinyget trace, client auto-scan, mobile not affected)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

SillyTavern remote access security checklist: 11 CVEs in 2026, the Node Brotli fix (CVE-2026-111497), 6 config.yaml keys

Ilan Kim — Wed, 28 Oct 2026 02:52:26 +0000

If you use SillyTavern from your phone or another PC, check three things now: the SillyTavern version, whether your Node.js has the 2026-10-21 security patch, and privateAddressWhitelist in config.yaml. The Node bug, CVE-2026-111497, went onto CISA's list of actively exploited vulnerabilities on 2026-10-27, and the official Docker image latest still ships an unpatched Node as of 2026-10-28.

This is a checklist for people who run SillyTavern, the self-hosted LLM chat frontend, with listen: true and reach it from other devices. On 2026-10-28 I ran 1.17.0 and 1.19.0 on my Mac, and ran the same commands on six Node versions to find a check that tells patched from unpatched builds.

I build backends in Node, and I was unpatched that morning too. My Mac was on v24.21.0, and all three Node versions on my Windows machine were pre-patch.

Without access control, SillyTavern refuses to start with listen: true

On 1.19.0 I turned off both the whitelist and Basic auth and started the server with listen: true. It printed one line and exited with code 1:

Your current SillyTavern configuration is insecure (listening to non-localhost). Enable whitelisting, basic authentication or user accounts.

So if you already use it remotely, you probably have at least one access control switched on. The exception is securityOverride: true. With that value the server only logs a warning and starts anyway.

The line to watch is the warning you get once the whitelist is on. It is a Warning: line saying the private address filter is off. The filter arrived in 1.18.0 and is off by default, so the warning shows up on every start.

The Blocked connection from line at the bottom of the capture is a connection the whitelist rejected. I connected to the same Mac through its LAN address and got a 403. That line comes back later, in the log check.

All 11 SillyTavern CVEs of 2026 are fixed in 1.18.0

SillyTavern had 11 CVEs published in 2026. I counted them on 2026-10-28 by pulling every GitHub Security Advisory with gh api. 1.16.0 fixed one, 1.17.0 fixed four, and 1.18.0 fixed six. Anything older than 1.18.0 is exposed to at least six of them.

CVE	Fixed in	What it is	GHSA severity	No auth needed
CVE-2026-26286	1.16.0	SSRF in asset download	high	no vector listed
CVE-2026-34522	1.17.0	`/api/chats/import` path traversal (file write)	high 8.1	no
CVE-2026-34523	1.17.0	Static file existence oracle	medium 5.3	yes
CVE-2026-34524	1.17.0	`/api/chats/export` and `delete` path traversal	high 8.3	no
CVE-2026-34526	1.17.0	`/api/search/visit` SSRF (incomplete validation)	medium 5.0	no
CVE-2026-44648	1.18.0	Existing sessions survive a password change	high 7.5	yes (user interaction)
CVE-2026-44649	1.18.0	Authentication bypass via SSO headers	critical 9.8	yes
CVE-2026-44650	1.18.0	Path traversal in extension deletion	critical 9.1	yes
CVE-2026-44651	1.18.0	Reflected XSS in the CORS proxy	medium	no vector listed
CVE-2026-44652	1.18.0	SSRF in the CORS proxy	medium	no vector listed
CVE-2026-46372	1.18.0	SSRF in the SearXNG search proxy	high 8.5	no

The "No auth needed" column comes from whether the GHSA's CVSS vector says PR:N. The most urgent one is CVE-2026-44650. It is critical 9.1 and needs no login. CVE-2026-44649 scores 9.8, but it only applies if you turned on SSO header authentication.

The two CORS proxy bugs only matter if you enabled enableCorsProxy. Its default is false. The GHSAs include reproduction steps; I'm not repeating them here.

Four of this year's CVEs are SSRF. The maintainers' answer was to add privateAddressWhitelist in 1.18.0, as written in GHSA-qg89-qwwh-5f3j. They also said future SSRF reports will only be accepted if they bypass that filter. In other words, turning the filter on is now your job.

One more for background. CVE-2025-59159, from 2025-10, is a DNS rebinding bug rated critical 9.6. 1.13.4 added the hostWhitelist setting to block it. That setting is also off by default.

Node2Shell (CVE-2026-111497) reaches SillyTavern through the responses it fetches

Node.js fixed CVE-2026-111497 in its 2026-10-21 security release and rated it High. The advisory title is "Brotli decoder out-of-bounds write permits remote code execution". If an application decompresses Brotli data from someone else with node:zlib, process memory can get corrupted.

Item	Details (checked 2026-10-28)
Patched versions	v22.23.4, v24.22.1, v26.12.1
No patch	20.x (EOL 2026-04-30), 25.x (EOL 2026-06-01)
Scores	nodejs.org High, NVD CVSS 4.0 9.2
Root cause	The Google Brotli decoder bundled in Node
KISA (Korea) Node.js advisory, 10-23	Lists 3 other CVEs, not this one
Exploitation	Added to CISA KEV 2026-10-27, remediation due 2026-11-10

Node2Shell is a community nickname; it appears on neither nodejs.org nor NVD. Searching by the CVE number gets you the right results. KISA is Korea's national internet security agency, and its Boho-nara site publishes Korean-language security advisories. If you only read the KISA notice, you miss this one.

Read the nodejs.org advisory itself. As of 2026-10-28, it does not mention any exploitation.

CISA added this CVE to its KEV (Known Exploited Vulnerabilities) catalog on 2026-10-27. NVD shows the same date and an SSVC exploitation: active entry. The KEV entry names Google Brotli as the product. Neither source says the exploitation targeted SillyTavern or Node.js.

SillyTavern sends requests to whatever API address you configure. I pointed it at a small server on my Mac that logs request headers, and this is what arrived:

{"method":"GET","url":"/v1/models","headers":{"accept":"*/*","accept-encoding":"gzip, deflate, br","authorization":"Bearer","user-agent":"node-fetch","host":"127.0.0.1:18080","connection":"close"}}

accept-encoding includes br. In 1.19.0, 30 files under src use node-fetch. node-fetch 3.3.2 decodes br responses with zlib.createBrotliDecompress(). The global fetch uses the same decoder.

Incoming request bodies are a different story. body-parser 1.20.4 only inflates deflate and gzip, and answers br with a 415. So the path to this bug is the responses SillyTavern fetches. API endpoints, the search proxy and asset URLs all count.

I did not send a malicious Brotli response; I stopped at headers and source code. If you use an API proxy whose operator you don't know, I'd treat the Node patch as more urgent.

process.versions.brotli can't tell you whether you're patched

Check the patch with node -v. If that leaves you unsure, a single zlib constant settles it. I ran the same commands on six Node versions:

process.versions.brotli reads 1.2.0 on both v24.21.0 and v24.22.1. The 22 line shows 1.1.0 before and after the patch. That's because Node did not upgrade the library; it cherry-picked the one fix.

The BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH constant is what differs. The three patched builds have it and the three unpatched builds don't. So don't use process.versions.brotli for this check.

I ran the same check on my Windows machine. Node there is managed by fnm, which I installed with winget. All three installed versions returned false for the constant. Over a remote shell, node wasn't found at all, because the PowerShell profile is what puts fnm on the PATH.

The official Docker image latest ships Node 24.21.0 as of 2026-10-28

I checked the registry metadata. The official latest and 1.19.0 images were both built on 2026-09-14. The NODE_VERSION in both image configs is 24.21.0.

Tag	Built	Bundled Node
`latest` (release)	2026-09-14	24.21.0
`1.19.0`	2026-09-14	24.21.0
`staging`	2026-10-28	24.22.1
Docker Hub `node:lts-alpine3.23`	2026-10-21	24.22.1

The official docs say "No action required" for Docker. That only holds once the image is rebuilt. Pulling latest again today gets you the same image.

The Dockerfile starts from node:lts-alpine3.23. That base image was rebuilt with 24.22.1 on 10-21. I expect a build from source to pick up the patched Node. staging is the development branch, so feature changes come along with it.

Check two versions, six settings and one log, in that order

1. Check the SillyTavern version

Look for a line like SillyTavern 1.19.0 at the top of the startup log; it should say 1.18.0 or later. The server prints it before it accepts any request, so you see it whatever your auth settings are.

On a local server without access control, pkgVersion in the /version response works too. With Basic auth on, this request gets a 401. Don't trust isLatest in the same response, because it doesn't query the remote. The request:

curl -s http://127.0.0.1:8000/version

2. Check Node

Run these in the same terminal you start SillyTavern from. The Node version: line at the top of the startup log shows the same value:

node -v
node -p "'BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH' in require('zlib').constants"

true means a patched build. For Docker, use docker exec <container-name> node -v.

3. Update Node

The route depends on how you installed it. The commands are from the official Node update docs, except the fnm row, which I added:

Install method	Commands
nvm (macOS, Linux)	`nvm install --lts`, then `nvm use --lts`
nvm-windows	`nvm install lts`, then `nvm use lts`
fnm	`fnm install 24.22.1`, then `fnm use 24.22.1` and `fnm default 24.22.1`
Windows winget	`winget install --id=OpenJS.NodeJS.LTS -e`
Homebrew	`brew update`, then `brew upgrade node`
Termux	`pkg update`, then `pkg upgrade nodejs-lts`
Docker	Rebuild from source, or wait for a new image

After updating, run check 2 again and restart SillyTavern. With fnm, changing only fnm default leaves the current shell on its old Node. In my run, the shell only switched to v24.22.1 after fnm use.

4. Update SillyTavern to 1.19.0

Since 1.17.0, engines requires >= 20, so update Node first.

5. Check six `config.yaml` entries

Defaults are from default/config.yaml in 1.19.0.

Key	Default	For remote access	Why
`whitelistMode`, `whitelist`	`true`, `::1` and `127.0.0.1`	Keep on, add only your phone's or VPN's address	Anything outside the whitelist gets a 403
`basicAuthMode`, `basicAuthUser`	`false`, `user`/`password`	Turn on and change the default password	The default credentials are public
`privateAddressWhitelist.enabled`	`false`	`true`	Covers the 4 SSRFs; the maintainers' recommendation
`hostWhitelist.enabled`	`false`	`true`, list the host names you use	The setting that addresses CVE-2025-59159
`enableCorsProxy`	`false`	Keep `false`	CVE-2026-44651, CVE-2026-44652
`securityOverride`	`false`	Keep `false`	Disables the startup check

The official docs recommend a VPN or a tunnel over port forwarding. If you're going to expose it straight to the internet anyway, get every row of this table right first.

6. If an LLM server runs elsewhere on your LAN, add its range to `allowedRanges`

By default the filter only allows loopback. A request to a backend on another PC gets blocked like this:

[Private Request Filter] Blocked request to private IP address: <LAN-IP>
FetchError: request to http://<LAN-IP>:9/v1/models failed, reason: Blocked request to private IP address: <LAN-IP>

After I added 10.0.0.0/8, the same request passed the filter and failed with ECONNREFUSED instead. Keep the range as narrow as the addresses you actually use.

7. Check the logs

access.log in the data folder records only connections that got through, once per IP. Connections the whitelist blocked appear only as Blocked connection from lines in the console. Basic auth returns 429 for 60 seconds starting from the sixth failure. During that window even the correct password is refused, and the console logs a Basic auth failed: Rate limited from line.

Takeaways

As of 2026-10-28, a SillyTavern you reach from other devices needs 1.18.0 or later for this year's 11 CVEs, a Node build that has the BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH constant (v22.23.4, v24.22.1, v26.12.1), and privateAddressWhitelist.enabled: true. The official Docker latest image still carried Node 24.21.0 that day, so pulling it again doesn't fix the Node side.

Unverified

Node updates on Termux (Android) installs: I have no device to run them on. The commands in the table are copied from the official docs.

The message you get when starting 1.17.0 or later on Node below 20: I didn't check it, because I didn't download a Node 18 binary. I only confirmed from the source that server.js has no version check.

node -v inside a container and the Node version of a self-built image: I couldn't check either, because this Mac has no Docker runtime. I used NODE_VERSION from the image config instead.

hostWhitelist blocking behavior: I didn't run it. I only confirmed the default value from the source.

The real effect of a malicious Brotli response on SillyTavern: I deliberately did not reproduce it. I stopped at the headers and the decoder path.

Brotli decoding paths in extensions and server plugins: I didn't trace them. I only looked at the core src.

Real-world exploitation targeting SillyTavern: I couldn't confirm any. CISA KEV and NVD only say the Brotli decoder was exploited. I couldn't independently confirm claims made in security vendors' posts either.

The CVSS 3.1 9.8 score for CVE-2026-111497: it appears only on some aggregator sites. NVD doesn't list it, so this post uses CVSS 4.0 9.2.

The update path for the winget Node.js LTS package: I didn't run it, because that package wasn't installed on my Windows machine. I didn't run the upgrade either.

Changelog

Version	Description
1.0	2026-10-28 first version (version checks on SillyTavern 1.17.0 and 1.19.0 and on six Node versions, four config startups, Docker image metadata, Windows fnm check, fnm switch, NVD and KEV lookup)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

ComfyUI MCP servers compared: comfyui-mcp, comfy-mcp and comfyui-mcp-secure in Claude Code, measured for ports, paths, tokens

Ilan Kim — Wed, 28 Oct 2026 02:52:15 +0000

If you want the widest feature set, pick comfyui-mcp; for official support, comfy-mcp; for the least exposure of your local file system, comfyui-mcp-secure. Run with their default stdio transport, none of the three opens a single port, so the real differences are how far each one reads and writes local files and how much model context its tool definitions consume.

This is for anyone about to connect a local ComfyUI to Claude Code. On 2026-10-28 I installed all three servers at pinned versions and measured them. The client was Claude Code 2.1.312 on macOS 27.0.1, and ComfyUI was 0.35.0 on the same Mac. Only the first-generation run used ComfyUI 0.33.1 on a Windows machine with an RTX 5090. I run this blog's own workflow with several MCP servers attached to Claude Code and Codex.

The security section is written from the defender's side only: whether your setup is affected, which versions and settings to change, and where to look for traces. Every test ran on the loopback interface of my own two machines and inside freshly created empty folders.

comfyui-mcp, comfy-mcp and comfyui-mcp-secure aim at different things

These three are not rivals doing the same job. They split into maximum features, official, and security-focused. The table below shows values I checked on 2026-10-28 through the GitHub API and the package registries; star counts and release dates are as of that day.

Repository	Package (measured version)	Language, license	Stars	Last release	Tools
artokun/comfyui-mcp	npm `comfyui-mcp@0.52.206`	TypeScript, MIT	871	2026-10-14	41
Comfy-Org/comfy-mcp	PyPI `comfy-mcp==0.10.0`	Python, AGPL-3.0 OR Commercial	308	2026-08-10	39
hybridindie/comfyui_mcp	PyPI `comfyui-mcp-secure==2.3.0`	Python, MIT	3	2026-10-06	53

comfyui-mcp is the largest community server. It bundles a Claude Code plugin, hooks, and --http and --tunnel modes in one package. The README says 38 tools, but the actual handshake returned 41.

comfy-mcp is the official server that Comfy-Org created in 2026-07. It does not open its own socket to ComfyUI; it shells out to comfy-cli instead. PyPI 0.10.0 is 47 commits behind main. The README's quick start also installs from a checkout rather than from PyPI.

comfyui-mcp-secure is a small server with 3 stars. Its selling points are workflow inspection, a path sanitizer and an audit log. Peleke/comfyui-mcp was also a candidate, but I dropped it: 2 stars and no pushes since 2026-03-13.

With the default stdio transport, none of the three opens a port

I started each server with its defaults and counted LISTEN sockets across its process tree. All three had zero. A stdio server is spawned by Claude Code as a child process and talks only over pipes. Here is the log:

## stdio 기본 — artokun comfyui-mcp@0.52.206
  LISTEN (none)
## stdio 기본 — comfy-mcp 0.10.0
  LISTEN (none)
## stdio 기본 — comfyui-mcp-secure 2.3.0
  LISTEN (none)

(The stdio 기본 headers are my log labels and mean "stdio default".)

Only two of them have an HTTP mode. comfyui-mcp --http bound to 127.0.0.1:9100. comfyui-mcp-secure with transport.remote.enabled bound to 127.0.0.1:8080. comfy-mcp is hard-coded to stdio.

Request	`comfyui-mcp --http`	`comfyui-mcp-secure` remote
No token	200	200
Unfamiliar Origin header	200	200
No token or wrong token, after setting `COMFYUI_MCP_HTTP_TOKEN`	401	no such setting
Correct token, same setting	200	no such setting

An HTTP mode without a token is an open door, even on loopback. The transport section of the MCP specification, 2025-11-25 revision, says servers must validate the Origin header and return 403 when it is wrong. Started without a token, both servers answered 200 to an unfamiliar Origin.

There is already a case that shows why this matters. CVE-2026-61568 in @zereight/mcp-gitlab was a flaw that let DNS rebinding reach its local Streamable HTTP transport; it was fixed in 2.1.30. It shows that an HTTP server bound to loopback can still be reached through a browser. I did not test whether the same path works against these two servers.

One more thing caught me. The default port of comfyui-mcp, 9100, is one that printers commonly use. On my Mac, a printer driver was already holding *:9100. Requests to 127.0.0.1:9100 did reach the MCP server, but changing the port with --port saves you the confusion.

comfyui-mcp and comfy-mcp read and write outside ComfyUI, even on the Desktop

I passed a freshly created ~/Desktop/mcp-scope-test/ path to the upload and output-path tools listed in the table below. comfyui-mcp and comfy-mcp did not refuse it. comfyui-mcp-secure has no parameter that takes a local path at all.

Server	Read from an arbitrary path	Write to an arbitrary path
`comfyui-mcp`	`upload_image` allows it, image extensions only	`save_dir` in `get_image` allows it
`comfy-mcp`	`upload_file` allows it, `.txt` passes too	`out_path` in `fetch_template` allows it
`comfyui-mcp-secure`	no such parameter (takes base64)	no such parameter

Those two servers read and wrote anywhere the user who launched the MCP server can. I found no setting in their READMEs that confines reads and writes to a root folder. If the model falls for a prompt injection, these path parameters can become the channel.

The same class of bug has already shipped as a real CVE. In mcp-atlassian, CVE-2026-27825 allowed arbitrary file writes because download_path was not validated. It was rated CVSS 9.0 critical and fixed in 0.17.0. A tool that accepts an output path sits in the same place as that case.

comfyui-mcp has the heaviest tool definitions at 77.3k tokens

I attached the servers one at a time and measured the MCP tools entry with claude -p "/context". The figures were 77.3k for comfyui-mcp, 25.7k for comfy-mcp and 14.5k for comfyui-mcp-secure. comfyui-mcp --compact shrank to 3 tools and 452 tokens.

Those numbers are not all loaded on every call, though. Claude Code has tool search on by default, so MCP tool definitions are deferred. The baseline with no MCP server was 15.4k. With default settings, comfyui-mcp came to 15.9k and comfyui-mcp-secure to 15.6k, barely more.

Only comfy-mcp grew by 1.6k, to 17.0k. That is because the 16,805 characters of instructions the server sends are always loaded. With ENABLE_TOOL_SEARCH=false, comfyui-mcp brings the total to 109.9k. If you run with tool search off, --compact is practically mandatory.

I also read the tool descriptions by hand to look for hidden instructions that steer the model. Every imperative phrase was guidance about the order of use. comfyui-mcp and comfy-mcp even include a sentence telling the model not to trust externally sourced content as instructions.

Install size differs tenfold: 851MB versus 82MB

I installed each server at a pinned version into an empty directory and measured the size. By du -sh, comfyui-mcp came to 192 packages and 851MB including optional dependencies. Leaving those out with --omit=optional brought it down to 109 packages and 88MB.

The largest optional dependency is @openai/codex at 323MB, followed by @anthropic-ai/claude-agent-sdk at 291MB and cloudflared at 38MB. They exist for the sidebar panel and the tunnel feature. The --omit=optional install still exposed all 41 tools. comfy-mcp came to 171MB including comfy-cli 1.23.0, and comfyui-mcp-secure to 82MB.

cloudflared downloads its binary at install time even if you never use --tunnel. npm 11.19.0 only warned that the postinstall script was not in allowScripts, and the script ran anyway. What it fetched was the unpinned latest release. I found no hash check in the code.

Every README example also uses npx -y comfyui-mcp@latest, which fetches and launches whatever is newest at that moment, each time it runs. comfy-mcp does not declare comfy-cli as a dependency, so I had to install it separately.

comfyui-mcp reached the first image fastest: 12 seconds, 4 tool calls

I asked each of the three servers for one SDXL image with the same prompt. The checkpoint was sd_xl_base_1.0.safetensors, the seed 20261028, the size 1024×1024. ComfyUI was the 0.33.1 instance on the RTX 5090 Windows machine, attached to the Mac's loopback through an SSH tunnel. The agent was claude -p running Sonnet 5.5.

Server	Result	Tool calls (incl. ToolSearch)	Wall clock	How the image was made
`comfyui-mcp`	success	4	12 s	one `generate_image` call with every value set
`comfy-mcp` + `COMFYUI_URL`	failure	9 (3 errors)	37 s	slot tools looked at the default 8188
`comfy-mcp` + `COMFY_LOCAL_URL`	success	14	89 s	fetched a template and edited 12 slots
`comfyui-mcp-secure`	success	3	14 s	wrote an API-format workflow directly

The images from the three servers were identical down to the pixel. In the end, each one fed the same graph to ComfyUI. The difference lay in the tool calls it took to build that graph.

Image: AI-generated (Stable Diffusion XL sd_xl_base_1.0, the output of this post's first-generation run).

In comfyui-mcp, a single generate_image takes seed, sampler and scheduler. The agent submitted, checked the status once and read the result, and that was all. comfyui_generate_image in comfyui-mcp-secure takes neither seed nor sampler, so the agent wrote the workflow itself and submitted it with comfyui_run_workflow.

The audit log of comfyui-mcp-secure recorded the list of nodes it inspected before submission, with the verdict allowed. In the default audit mode it only records risky nodes and does not block them.

comfy-mcp failed on the first attempt. When I pointed the remote-oriented COMFYUI_URL at the tunnel, list_workflow_slots returned nothing but Error executing tool. Running comfy-cli directly with the same setting gave cannot reach http://127.0.0.1:8188/object_info.

For another port on the same machine, such as an SSH tunnel, set only COMFY_LOCAL_URL. The README's Which address variable do I want? section spells out this distinction. COMFYUI_URL moves only the submission and job tools, and the remaining tools keep looking at the default 8188. After switching to COMFY_LOCAL_URL, it succeeded in 89 seconds.

The generate_image tool in comfy-mcp accepts only checkpoint and prompt. The only way to pin the seed was to edit template slots, and that back-and-forth is why the tool calls climbed to 14. ComfyUI's execution took 10.6 seconds on the first run. Later runs hit the cache because the graph was the same, so I did not compare GPU time.

The default template of generate_image also differed from the docs. The comfy-mcp 0.10.0 README says generate_image runs the SD1.5 default template. The installed package's code uses image_z_image_turbo instead, and a code comment says default was removed from the gallery.

Indeed, passing default to fetch_template produced Error executing tool fetch_template. image_z_image_turbo requires a qwen-family text encoder and the z-image model. If all you have is an SDXL checkpoint, switch the template with COMFY_T2I_TEMPLATE. You also need the environment variables that match the slot names; the code comment gives COMFY_T2I_CHECKPOINT_SLOT as an example.

An MCP server security checklist in four steps

Here is how the three servers measure up across six areas first. Each cell is a value I confirmed on 2026-10-28 by measurement or by reading the code.

Area	`comfyui-mcp`	`comfy-mcp`	`comfyui-mcp-secure`
Transport and auth	`stdio` default, HTTP token optional	`stdio` only	`stdio` default, no HTTP auth
Path scope	reads and writes arbitrary paths	reads and writes arbitrary paths	no local path parameters
Confirmation for risky actions	no server-side confirmation	user confirmation for 6 actions such as node installs	watches 159 risky nodes, warns only by default
Context	77.3k, 452 with `--compact`	25.7k + instructions	14.5k
Secrets and audit	returns ComfyUI launch arguments	returns launch arguments	whitelisted fields only, audit log per call
Supply chain	`@latest` examples, `cloudflared` downloaded without a hash	PyPI 47 commits behind main	unpinned `uvx` examples

All three had zero GitHub security advisories. No advisories does not mean no flaws, so check your own setup in the order below.

First, check whether your setup is affected

Start with which servers are attached and which transport they use. If you turned on an HTTP mode, check for open ports.

List the servers you have attached:

claude mcp list

Check the ports MCP servers have opened. If you only use stdio, no server process should show up here:

lsof -nP -iTCP -sTCP:LISTEN

Then search your config files for --http, --tunnel and transport.remote.enabled.

Pin patches and versions

Write down the version you checked instead of @latest or an unpinned uvx. Upgrade only after reading the release notes.

claude mcp add comfyui -- npx -y comfyui-mcp@0.52.206

Pin Python servers as well:

uv tool install "comfyui-mcp-secure==2.3.0"

If you install comfyui-mcp yourself, use --omit=optional to avoid the cloudflared download.

Narrow the settings

Turn off what you don't use to shrink the exposed surface. All of the following are settings the servers already provide.

If you really need an HTTP mode, set COMFYUI_MCP_HTTP_TOKEN for comfyui-mcp. The HTTP mode of comfyui-mcp-secure has no built-in auth, so you are better off using it over stdio.
For comfyui-mcp-secure, change security.mode in ~/.comfyui-mcp/config.yaml to enforce and list the nodes you use under allowed_nodes. According to the code, an empty list blocks nothing even in enforce. The default audit only records, and I did not run the blocking behavior.
If you use the panel feature of comfyui-mcp, lower COMFYUI_MCP_CODEX_SANDBOX to read-only or workspace-write. The default in the code is danger-full-access, and the README does not mention that default.
Run ComfyUI on 127.0.0.1 only, without --listen. Don't put secrets in ComfyUI's launch arguments: comfyui-mcp and comfy-mcp pass the launch arguments from /system_stats straight to the model.

Check for traces

Where a record of what happened ends up differs by server.

comfyui-mcp-secure writes one JSON line per call to ~/.comfyui-mcp/audit.log.
I found no built-in audit log in comfyui-mcp or comfy-mcp. Look for unfamiliar files uploaded to ComfyUI's input folder.
Files written through save_dir or out_path land outside the ComfyUI folder. Search your home folder for recently created images and JSON files.

Which server to pick depends on how you work

If you want an agent to drive ComfyUI deeply, comfyui-mcp does the most. In exchange, pair it with an --omit=optional install, a pinned version and stdio. If you run with tool search off, add --compact too.

If you want official support and user confirmation gates, choose comfy-mcp. When connecting through a tunnel or another port, get COMFY_LOCAL_URL right first. Before actions such as installing nodes or exposing the network, the server asks for confirmation through MCP elicitation. Note, though, that the PyPI release has been frozen since 2026-08-10, and the license is a dual choice between AGPL-3.0 and a commercial license.

If you would rather never hand local paths to MCP tools, comfyui-mcp-secure fits. It does still have tools for installing nodes and downloading models, so files on the ComfyUI side can change. It is the only one of the three with no local path parameters and an audit log. It is a small 3-star project, so keep an eye on whether maintenance continues.

Takeaways

All three servers open no port under default stdio, but comfyui-mcp and comfy-mcp read and write arbitrary local paths while comfyui-mcp-secure takes none and keeps an audit log. Pin versions, keep stdio (or set a token for HTTP), install comfyui-mcp with --omit=optional, and add --compact if you turn tool search off.

Unverified

Tunnel and external exposure modes: I did not run comfyui-mcp's --tunnel or any non-loopback bind. Exposing a server to the outside is out of scope for this post, so for those modes I only read the README and the --help text.

MCP servers launched on Windows: I ran all three servers on macOS only. Path handling and port conflicts may behave differently on Windows.

Unknown vulnerabilities in the three servers: zero GitHub security advisories only means no advisory has been published. I did not audit the full code.

Secondary MCP CVE tallies: figures such as "30 MCP CVEs in 60 days" come from secondary sources, so I left them out of the body. The cases in the body are only CVEs I checked directly in GitHub Advisory and OSV.

comfyui-mcp refusing unauthenticated non-loopback binds: --help says it refuses an unauthenticated non-loopback bind unless --allow-unauthenticated-non-loopback is given. I did not test a non-loopback bind, so I could not confirm that refusal.

The relative-path sanitizer: the comfyui-mcp tool descriptions and the comfyui-mcp-secure README say parent paths are rejected. That describes relative names inside the ComfyUI folder. I did not test parent-path strings.

Real behavior of the comfyui-mcp panel orchestrator: I confirmed the orchestrator's permission default in the code only. I did not launch the feature to see whether it actually runs with that permission.

Changelog

Version	Description
1.0	2026-10-28 first version (macOS Claude Code 2.1.312; ports, paths, context, install size and an RTX 5090 first-generation run measured for all three servers)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

NovelAI V5 upscaling measured: Enhance at 35 and 45 Anlas vs ComfyUI Anima i2i, and how much the style shifts (ΔE)

Ilan Kim — Thu, 01 Oct 2026 04:11:06 +0000

NovelAI's Enhance changed V5 images more than a local Anima i2i pass in ComfyUI did: the mean color difference from the original (ΔE2000) was between 10 and 15 for Enhance, and between 8.7 and 10.4 for Anima i2i even at denoise 0.55. If you only want a bigger image, the standalone Upscale at 1 Anlas stayed closest to the original.

This is for anyone who has hesitated over which route to take when enlarging a V5 image. On 2026-10-01 I prepared three originals with nai-diffusion-5-full, ran them through NAI Enhance 1.5×, Enhance Max and the standalone Upscale, and then ran the same originals through 15 ComfyUI jobs on an RTX 5090. A few terms if NovelAI is new to you: Anlas is NovelAI's generation credit, Enhance is the web UI option that enlarges an image and redraws it, and Anima is the model I run locally in ComfyUI. I usually generate in NovelAI first and move to Anima when I get stuck.

Enhance 1.5× cost 35 Anlas, Max cost 45 Anlas

Even on Opus, NovelAI's top subscription tier, Enhance and Upscale are not free. One of the conditions for free generation is that no other image is used as a base, so feeding in an existing picture takes Anlas off your balance (subscription page checked 2026-10-01).

I ran each action in the web UI and checked the balance after every one. Generating the originals cost 0 Anlas, as in the earlier post. Here is what each action deducted:

Action	Output size (portrait original)	Anlas deducted
Original generation 832×1216, 28 steps	832×1216	0
Standalone Upscale	1664×2432	1
Enhance 1.5×	1280×1856	35
Enhance Max	1467×2144	45

The two portrait images and the one landscape image all cost the same. That is higher than the 30 and 38 written in a community tool. The button in the Enhance window also showed 35 and 45, so look at that number before you click.

Enhance output records a strength 0.5 i2i request

Enhance output PNGs carry the request that produced them. NovelAI hides generation data inside its PNGs (the "stealth metadata" covered further down), and opening it shows the request as it was sent. Both levels were an Img2ImgRequest with strength 0.5, noise 0 and 28 steps. The two levels differed like this:

Item	Enhance 1.5×	Enhance Max
i2i request resolution	1280×1856	832×1216 (original size)
Final output	1280×1856	1467×2144
End of prompt	`-2::upscaled, blurry::,` appended automatically	nothing appended
Seed	new random value every time	new random value every time
Character prompts	carried over from the original	carried over from the original

The i2i request size was the enlarged size for 1.5× and the original size for Max. Max also had upscaled_enhance: true recorded separately, so Max appears to enlarge the image after the i2i pass.

Metadata alone cannot settle the processing order inside the server, so I left that as unverified. Magnitude 2 in the Enhance window is the same value as Strength 0.5.

The seed changes every time you click. Feeding in the same original again gives a different result, so save a result you like right away.

Enhance changed the image more than Anima i2i at 0.55

The reference is the original enlarged to the output size with Lanczos. ΔE2000 looks at color difference, and grayscale SSIM looks at how much of the lines and shapes survive. The values are the range across the three originals:

Method	Scale	Mean ΔE	SSIM	Cost
NAI standalone Upscale	2×	0.85~1.04	0.966~0.981	1 Anlas
ESRGAN (`RealESRGAN_x4plus_anime_6B`)	2×	2.07~2.59	0.904~0.931	0
Anima i2i denoise 0.25	1.5×	4.33~5.72	0.717~0.790	0
Anima i2i denoise 0.40	1.5×	6.29~7.90	0.615~0.700	0
Anima i2i denoise 0.55	1.5×	8.69~10.44	0.555~0.631	0
Anima i2i denoise 0.40	2×	5.38~6.95	0.693~0.765	0
NAI Enhance 1.5×	1.5×	10.63~15.43	0.481~0.606	35 Anlas
NAI Enhance Max	about 1.76×	10.19~14.29	0.498~0.638	45 Anlas

By the numbers, Enhance changed the image the most. Apart from the background image, saturation changed by 0.03 or less. SSIM fell at the same time, so the lines and shapes changed too. The exception is Enhance 1.5× on the background image, where saturation rose by 0.10 and the blue channel by 19.

Cropping the face shows the same order. Upscale is hard to tell apart from the original. Enhance 1.5× redrew the bangs and the eye highlights. Max changed even the eye shape and the irises. Anima i2i 0.40 kept the outlines closer to the original.

The usual community answer is that moving to a local model changes the style because the checkpoint is different. I had taken that on trust and assumed Enhance would be the safe option. Yet Enhance, which uses the same V5 model, changed the image just as much. Even with the same model, an i2i pass changes this much.

In the two-character image, Enhance kept the eye color and Anima changed it

The difference was clearest on the two-character original, which I generated with the prompt split across two character prompt slots. The blue-haired character with glasses has blue eyes in the original. Enhance kept the blue eyes at both levels. Anima i2i turned them green from 0.40 on.

Green is the other character's eye color. The glasses frames also went from black to gold. On the Anima side I used core nodes only, so both characters' attributes were written on a single line.

That line contains only green eyes, not blue eyes. The NAI character slots did not have blue eyes either. This one image cannot tell whether the cause is the single-line prompt or the difference between models.

The Enhance request carried both character slots unchanged. The glasses frames, though, became thick and square, and Max also changed the shape of the mouth. In this one image, the eye color survived and the details were redrawn.

Sign lettering was rewritten by every i2i pass

On the rainy neon street, no i2i pass kept the lettering. Enhance changed the layout and colors of the signs wholesale. Anima i2i 0.40 kept part of the large sign's shape, and at 0.55 that changed as well.

Most of the sign lettering in the original is meaningless characters anyway. It is still a problem if you liked the sign design, and in that case you should use only Upscale or ESRGAN.

Local ComfyUI post-processing on an RTX 5090: 2 to 38 seconds per image, 0 Anlas

The local setup is ComfyUI 0.33.1 on Windows 11, with torch 2.11.0+cu128 and an RTX 5090 32GB. I used core nodes only, with no custom nodes, and queued the 15 jobs one after another through the HTTP API (POST /prompt). Run times per job type were:

Job	Pipeline	Run time
ESRGAN 2×	`UpscaleModelLoader` 4×, then Lanczos to 2× size	1.63~1.66 s
Anima i2i 1.5×	Lanczos 1.5×, then `VAEEncode` and `KSampler` 30 steps	17.77~19.17 s
Anima i2i 2×	Lanczos 2×, then the same i2i	37.73~38.28 s

Anima ran at cfg 4.5 with er_sde and simple. The seed was 20261001, with no artist tags. The first run took 21 seconds because of model loading, so I left it out. The times are for this one GPU.

Anima is the only local model I kept. Its weights are non-commercial, but the images it generates can be used commercially; the Anima README says so. NoobAI-XL, which is on the same PC, prohibits commercial use of its outputs, so I left it out (checked 2026-10-01).

Stealth metadata disappears on a ComfyUI save but survives webp

NovelAI PNGs hide the prompt in the alpha channel, with the settings stored alongside it in the least significant bits. This is what NovelAI's stealth metadata is. I reimplemented the logic of the official reader and read the file at each stage:

Stage	Result
NAI original PNG, Upscale and Enhance output	survives
macOS `sips` PNG re-save	survives (text chunks are lost)
Lossless webp, lossy q90 webp (Pillow, sharp)	survives
ComfyUI `SaveImage` PNG	lost (saved as RGB, no alpha)
JPEG conversion	lost
Half-size resize (one original)	lost (`magic not found`)

If you only convert to webp and upload, the full prompt goes along with it. It read back intact even from a q90 lossy webp.

The original PNG also has the prompt in its Comment and Description text chunks. To hide it, strip both the alpha channel and the text chunks, then read the final file again before uploading to confirm.

One pass through ComfyUI and the NAI metadata is gone. In its place, SaveImage writes the workflow as a prompt chunk. If you need the NAI generation info, keep the original PNG separately.

Choose by how much of the original you want to keep

If you only want to enlarge the image as it is, the NAI standalone Upscale stays closest. If you have a local GPU, ESRGAN also stays around ΔE 2.
If there are several characters and you don't mind the details being redrawn, look at Enhance first. In this round's single two-character image, it kept the eye color. The result is different every time, so save it right away.
To save Anlas, start Anima i2i at denoise 0.25 to 0.40. With several characters, check the result with a crop.
For backgrounds where signs or lettering matter, avoid i2i and use only Upscale or ESRGAN.

All the pictures in this post were made with AI. Images: AI-generated (NovelAI Diffusion V5, ComfyUI Anima; cover image OpenAI Images).

Takeaways

NAI Enhance (35 or 45 Anlas) redrew V5 images more than local Anima i2i at denoise 0.55, while the 1 Anlas standalone Upscale and ESRGAN stayed closest to the original. Every i2i pass rewrote the sign lettering, and a webp conversion keeps the prompt in the stealth metadata, so strip it before you post.

Unverified

The internal processing order of Enhance: I could not confirm it. The metadata only records the request size and the upscaled_enhance value, and it does not show at which stage the server enlarges the image.

Seed-to-seed variance of Enhance results: I did not measure it. There is only one result per setting, so I don't know how much ΔE moves across repeated runs.

Enhance strengths other than Magnitude 2: I did not run them. I used only the default of 2 and did not check the price or the amount of change at other strengths.

Processing time on the NAI side: I did not measure it. A person clicked one image at a time, so all I have is a rough sense of the time, and queue waits were mixed in, so I kept it out of the table.

The Curated model and other local models: out of scope. The originals used only nai-diffusion-5-full, and locally I ran only Anima.

Changelog

Version	Description
1.0	2026-10-01 first version (9 NAI Enhance 1.5×, Max and Upscale runs plus 15 ComfyUI jobs, measuring Anlas, ΔE, SSIM and metadata)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Crack cash payouts: the 8.8% is other-income tax, not a fee — what you receive, May filing, business registration

Ilan Kim — Wed, 30 Sep 2026 08:44:45 +0000

When you convert Crack cash to money, the 8.8% that disappears is not a fee: it is income tax withheld on "other income" (기타소득) under Korea's Income Tax Act, so converting KRW 1,000,000 leaves KRW 912,000 in your bank account. If you have little other income, you can get most of it back by filing Korea's comprehensive income tax return in May.

Crack (크랙) is a Korean AI character-chat platform run by Wrtn (뤼튼); creators earn "cash" there when users spend paid Crackers on their works. I wrote this for creators who are building up cash on Crack. I've worked on payment and settlement code as a backend developer. On 2026-09-30 I saved the original text of Crack's announcement and cash guide, then recomputed the 8.8% from the articles of the Income Tax Act. I also read the Crack cash screen on my own account and the tax calculation in Crack's public web code. This is not tax advice. Your actual tax depends on your own income mix and the facts of your situation.

The 8.8% is withholding tax on other income

Other income (기타소득) is the Korean tax category for irregular income such as lecture fees, and the payer withholds tax before paying you. The 8.8% is exactly what the other-income withholding formula produces. 60% of the payment is deducted as deemed necessary expenses, and the remaining 40% is taxed at 20%. Local income tax of 10% of that is added on top.

Here is the calculation for a KRW 1,000,000 conversion:

Conversion           KRW 1,000,000
Other-income amount = 1,000,000 × (1 − 0.6) = 400,000   Income Tax Act Enforcement Decree Art. 87(1-2)
Income tax          = 400,000 × 20%          =  80,000   Income Tax Act Art. 129(1)6(d)
Local income tax    = 80,000 × 10%           =   8,000   Local Tax Act Art. 103-13(1)
Total KRW 88,000 = 8.8% of the payment, deposit KRW 912,000

In Korean, those citations are 소득세법 시행령 §87 1의2, 소득세법 §129①6라 and 지방세법 §103의13①.

Crack's own documents point the same way. The screen where you register your conversion details carries a personal-data collection notice. As its legal basis it cites Income Tax Act Articles 21, 127, 145 and 164. Article 21 defines other income, and Article 145 sets out how other income is withheld. Article 144, the withholding provision for business income, is not on the list.

The Crack Originals notice is more direct. On payouts to original authors, it says they are "transferred to your account after 8.8% other-income tax withholding" ("기타소득세 8.8% 원천징수 후 계좌로 이체"). The 3.3% that Korean freelancers usually see deducted is business-income withholding. Crack cash is handled differently.

Converting KRW 1,000,000 puts KRW 912,000 in your account

What lands in your account is the conversion amount minus 8.8%. The rate at which cash accrues depends on your work's rating and whether it is registered for Crack Only. Your paid Cracker usage is multiplied by that rate, and the resulting cash arrives on the 1st of the following month.

As an example, I took a work with 100 million paid Crackers used in a month. I picked a large number to reach the range where the deduction actually bites. I assumed all accrued cash is converted at once:

Tier	Accrual rate	Cash earned (KRW)	8.8% withheld (KRW)	Deposit (KRW)
Regular creator, Safety	1.0%	1,000,000	88,000	912,000
Official creator, Unsafety (from 9/1)	1.0%	1,000,000	88,000	912,000
Official creator, Safety	1.5%	1,500,000	132,000	1,368,000
Official creator, Unsafety + Crack Only	2.0%	2,000,000	176,000	1,824,000
Official creator, Safety + Crack Only	2.5%	2,500,000	220,000	2,280,000

Crack Only started on 2026-08-12. Only official creators' works can apply (per the notice as of 2026-09-30). In exchange for publishing a work exclusively on Crack for 18 months, the rate goes up by 1 percentage point. Each series has a cumulative payout cap of KRW 1 billion, counted afresh from September 1.

The conversion screen calculates the same way. In the public web code, the amount you enter is multiplied by a taxRate supplied by the server. Fractions of a won are dropped. The screen shows the requested payout amount (지급 요청 금액) and the tax deduction (세금 공제). Below those come the expected payout amount (예상 지급 금액) and expected payout date (지급 예상일). The guide adds that the tax calculation on the screen is an example.

My account holds 0 cash, so I couldn't bring up that screen myself. When you tap 현금으로 바꾸기 (Convert to cash), you're first told to register your conversion details (전환 정보). The guide says Crack takes some time to verify the registered details.

Cash-out starts at KRW 10,000 and pays on the 10th and 25th of each month

Crack announced a revamp of its payout policy on 2026-07-29. From September 1, cash can be converted to money. The name also changed from Wrtn cash to Crack cash. Exchanging cash for goods in the old cash store ended that day.

The conversion terms are in the Crack cash guide (revision of 2026-09-03):

The minimum request is KRW 10,000, with no cap per request.
There is no conversion fee.
Payouts go out on the 10th and 25th of each month (the next business day if that date is a holiday), and you must apply at least 5 business days before a payout date.
You register your name, resident registration number and a bank account in your own name, and submit copies of your ID and bankbook.
Minors aged 14 or older also submit a guardian consent form, a family relation certificate and the guardian's ID. Their limits are KRW 2,000,000 per request and KRW 10,000,000 per month.

The balance is shown in won, not in cash units. In its Super Week notice, Crack said one Cracker is worth KRW 1. But I found no sentence stating that 1 cash equals KRW 1. The amounts in this post assume 1 cash = KRW 1.

Conversions of KRW 125,000 or less are not taxed under the statute

Under Income Tax Act Art. 84, no tax is imposed when the other-income amount per payment is KRW 50,000 or less. Working backward with the 60% expense deduction, the boundary is a KRW 125,000 conversion. Up to KRW 125,000 the tax is KRW 0; at KRW 200,000, KRW 17,600 is deducted.

However, Crack's documents don't say whether it treats one conversion as one payment under that article. The web code has no branch by amount either; it applies the same rate. The guide only says tax "may be" deducted.

I don't recommend splitting conversions into small pieces to stay under the boundary. Without knowing how Crack counts payments, all you'd get is more requests.

Cash saved over several months is reported in one lump on the payment date

Withholding happens on the day money is actually paid out. If you convert several months of cash at once, it is not split by the month it accrued. The guide says it is reported in a lump sum based on the payout date. It also tells you to keep that in mind when filing your comprehensive income tax return.

So on the payment statement Crack files with the National Tax Service, the amount is grouped under a single payout date. The figures to check in May are your conversion history, not your accrual history. If you note the amount and the deduction for every conversion, reconciling later is easy.

Crack's 8.8% and May income tax: at KRW 3,000,000 of other-income amount or less, you can choose separate taxation

Korea's comprehensive income tax return (종합소득세) for the previous year is filed in May. As long as Crack cash is treated as other income, which path you take depends on your total other-income amount for the year. If your other-income amount is KRW 3,000,000 or less, you can choose separate taxation.

That total also includes other withheld other income, such as lecture fees. Other income that the statute always taxes separately or always combines is left out of it (Income Tax Act Art. 14(3)8(a)).

If Crack is your only such income and the 60% expense deduction applies, the boundary is KRW 7,500,000 of conversions. If your actual expenses exceed 60% and you deduct those instead, the boundary goes up (proviso to Enforcement Decree Art. 87(1-2)).

If you choose separate taxation (분리과세), the withholding is final. If you have no other comprehensive income, you don't need to file in May (Art. 73(1)8). In return, you don't get back the tax already withheld.

If you choose to combine (합산), it is added to your other income and recalculated at the basic progressive rates. I ran the numbers for someone with no income besides Crack. I included only the KRW 1,500,000 basic personal deduction and the KRW 70,000 standard tax credit:

Annual conversions (KRW)	Other-income amount (KRW)	National tax withheld (KRW)	Separate taxation	Tax determined if combined (KRW)	National tax refunded (KRW)	Refund incl. local tax (KRW)
1,000,000	400,000	80,000	Available	0	80,000	88,000
7,500,000	3,000,000	600,000	Available	20,000	580,000	638,000
20,000,000	8,000,000	1,600,000	Not available, must combine	320,000	1,280,000	1,408,000
50,000,000	20,000,000	4,000,000	Not available, must combine	1,445,000	2,555,000	2,810,500

Once that total exceeds KRW 3,000,000, there is no choice. Combining is mandatory and you file by May 31. Even someone who converted KRW 50,000,000 in a year gets a refund if Crack is their only income. Withholding is 20% of the income amount. The tax on a KRW 18,500,000 tax base at the basic rates comes out lower than that.

If you have a salary, combining costs you more from the 24% marginal bracket up

If you have employment income, the other-income amount sits on top of it. Compare the 20% withholding with your marginal rate. I calculated for an employee who converted KRW 10,000,000 in a year, which is an other-income amount of KRW 4,000,000:

Existing tax base (KRW)	Marginal rate	National tax difference if combined (KRW)
10,000,000	6%	Refund 560,000
30,000,000	15%	Refund 200,000
70,000,000	24%	Additional payment 160,000
120,000,000	35%	Additional payment 600,000

If the added amount stays inside the 6% or 15% bracket, combining works in your favor. From the 24% bracket up, combining means paying more. If the added amount crosses a bracket boundary, compare the tax with and without combining. When combining costs more and that eligible total is KRW 3,000,000 or less, ending it with separate taxation is the better choice.

The KRW 4,000,000 in this example is over KRW 3,000,000, so combining is mandatory. This is a simple comparison that leaves out any change in deductions on the employment side.

Creators paid out every month should check the business registration test

Right now Crack handles cash conversions as other income. But the platform doesn't decide the income category. Income Tax Act Art. 19(1)21 does. Income from activity carried on continuously and repeatedly for profit is business income.

Korea's National Tax Service published a tax guide for YouTubers and other new types of business, 유튜버 등 신종업종 사업자 세무안내 (PDF, Korean). It says that even without a matching industry code, doing the activity continuously and repeatedly creates an obligation to register as a business. The test is scale and frequency, not whether you have registered. A creator who gets paid out every month may well meet it.

If it becomes business income, a few things change:

Necessary expenses are no longer a fixed 60%; they come from your books or the official expense rates.
If you create alone, it may qualify as VAT-exempt personal services. The basis is VAT Act Art. 26(1)15 and Enforcement Decree Art. 42.
Under the National Health Insurance dependent rules, business income is counted separately.

Health insurance dependents: KRW 20,000,000 a year; dependent tax deduction: KRW 1,000,000 of income amount

If you're listed as a dependent on a family member's National Health Insurance (피부양자) or claimed as a dependent on their tax return (부양가족), this part may matter more. To stay a health insurance dependent, your total income must be KRW 20,000,000 a year or less. Business income is looked at separately. With no business registration and KRW 5,000,000 a year or less, it is treated as zero.

I couldn't confirm whether other income is counted as gross receipts or as income amount here. If it's counted as income amount, the boundary is KRW 50,000,000 of conversions.

The basic deduction for a dependent requires a total income amount of KRW 1,000,000 or less. With Crack income only, that is KRW 2,500,000 of conversions. Whether amounts taxed separately count toward it is left as unverified.

Finding the withholding record for Crack payouts on Hometax

Hometax (홈택스) is the National Tax Service's e-filing site. Type 원천징수영수증 (withholding receipt) into its integrated search (통합검색) and 14 menus come up. Only one of them is for the person receiving income: 지급명세서(원천징수 내역)등 조회 (payment statement / withholding history lookup), under 나의 소득·연말정산 (my income and year-end settlement). The rest are for companies making payments.

The May return is filed under 세금신고 (tax filing) → 종합소득세 신고 (comprehensive income tax return). If you missed the deadline and only want your refund, there is a separate 종합소득세 기한후 환급신고 (late refund filing for comprehensive income tax) menu. I couldn't confirm when Crack payouts show up on the screen after you log in.

Checklist before you convert your cash

Prepare a copy of your ID and a copy of a bankbook in your own name. Minors need three additional guardian documents.
Verifying conversion details takes time, so register them well ahead of the 5-business-day cutoff before a payout date.
Every time you convert, save the tax deduction and deposit amounts shown on the screen.
Before May of the following year, check the Crack payouts in Hometax's payment statement lookup.
If your eligible other-income amount for the year (Crack included, always-separate items excluded) is KRW 3,000,000 or less, choose whichever of separate taxation or combining works in your favor. If it's more, file a combined return.
If payouts keep coming every month, first ask your tax office or a tax accountant whether it counts as business income.

Takeaways

The 8.8% Crack deducts on cash-out is other-income withholding, not a fee, and if your other income is small, filing in May can get most of it back. Record every conversion, check the payout on Hometax before May, and if you're paid out every month, ask a tax office or accountant whether it is business income.

Unverified

This post is not tax advice. I couldn't confirm the items below from original documents or screens, so they are stated with conditions. The conclusion can change depending on your facts.

Cash-to-won conversion: there is no official statement. There is only a balance shown in won and a notice saying one Cracker is worth KRW 1.
Which item of other income applies: Crack hasn't said. Whether it's Art. 21(1)15 or item 19, the deemed expense is 60% either way, so the 8.8% is the same.
Whether the minimum taxable threshold applies per conversion: not confirmed. The web code applies the same rate regardless of the amount.
Whether it counts as business income: this is a question of fact. I found no industry code or official ruling for AI character creation.
Whether it qualifies as VAT-exempt personal services, and whether the penalty for not registering applies: not confirmed.
Expense rates for tax year 2026: they are published in April 2027. So I did not calculate the tax for the business-income case.
How other income is counted for health insurance dependents: I couldn't confirm whether the basis is gross receipts or income amount.
Whether separately taxed amounts count toward the dependent tax deduction: I couldn't settle it from the statute alone.
When payouts appear on Hometax: unknown, since I didn't see the screen after logging in.
The actual rate on the conversion screen: I couldn't bring the screen up because my account balance is 0. I don't know whether the server's taxRate is 0.088.
How long the first payout takes to arrive: I haven't seen a case from the September payouts.

Changelog

Version	Description
1.0	2026-09-30 First English version, adapted from the Korean original (Crack announcement and cash guide text, Income Tax Act articles cross-checked, conversion math reproduced, Crack cash screen checked)

Cover image: AI-generated (OpenAI Images)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Parsing VRM in Flutter without a package: vrm_dart fails on VRM 1.0 (LateInitializationError), so read the GLB chunks yourself

Ilan Kim — Tue, 22 Sep 2026 08:20:59 +0000

You do not need a package to read VRM metadata in Flutter. A VRM file is a glTF 2.0 GLB: a 12-byte header, then a JSON chunk carrying the model name, author, license, expressions, mesh list and the index of the thumbnail, then a BIN chunk carrying the thumbnail bytes. The one Dart library that exists, gatari/vrm_dart, throws LateInitializationError on every VRM 1.0 file and, on VRM 0.x, returns a null thumbnail unless the image happens to be named "Thumbnail". The parser I ended up with is 101 lines of dart:convert and dart:typed_data and reads all of it on both versions.

This is a full rewrite of a post I wrote in December 2024. It is for anyone who needs to show a VRM model's name, author and thumbnail inside a Flutter app. On 2026-09-22, on macOS Apple Silicon with Flutter 3.47.2 and Dart 3.13.2, I ran vrm_dart and a hand-written parser against five sample files, then dropped the parser into a Flutter package and ran flutter test.

The problem

Feed a VRM 1.0 file to vrm_dart exactly the way the 2024 post did. parse() returns, and the first access to the metadata throws:

== Seed-san.vrm (10917800 B)
parse(): ok
vrmMeta access: LateError: LateInitializationError: Field 'vrmMeta' has not been initialized.
thumbnailByteData: null

The 2024 situation was this. The project had a Unity viewport and a Flutter UI, and the model list screen lived on the Flutter side, so the Flutter side had to read VRM metadata on its own. Unity has UniVRM and Unreal has VRM4U; Flutter had nothing. What I found was gatari/vrm_dart, a repository never published to pub. I copied two files into the project, and these three lines got me the thumbnail and part of the metadata:

final vrmByteData = await File(path).readAsBytes();
final vrmParser = VrmFileParser(ByteData.sublistView(Uint8List.fromList(vrmByteData)));
vrmParser.parse();

The post ended with the regret that BlendShapeGroup and the mesh list were out of reach. Since then the ground has moved. VRoid Studio exports VRM 1.0 from v1.20.0, released 2023-03 (checked 2026-09-22), so 1.0 files are now common. vrm_dart has had no commits since 2021-10-13, and a pub.dev search for vrm still returns zero VRM packages.

VRM 0.x files trip it up in two more ways. A file with no images at all, like the add-on test fixture minimal.vrm, dies inside parse():

== minimal.vrm (4660 B)
parse(): _TypeError: type 'Null' is not a subtype of type 'List<dynamic>' in type cast

And a 0.x file that does have a thumbnail still comes back with thumbnailByteData null when the image is not named "Thumbnail", even though the metadata's texture field points straight at it.

What the measurements show

vrm_dart only ever looks at the extension named VRM. VRM 1.0 stores everything under VRMC_vrm, with a different metadata schema and different names for the main fields: title became name, author became authors, licenseName became licenseUrl, and the thumbnail moved from texture to thumbnailImage. With no branch for that, the late field vrmMeta is never assigned, and the first read throws.

Start with the file structure. A VRM is a GLB, the binary container for glTF 2.0. The first 12 bytes are the header: the magic glTF, version 2 and the total length, each a little-endian uint32. Chunks follow. Each chunk is a length and a type, 4 bytes each, then the payload. The standard chunk types are JSON and BIN; unknown types are skipped. All five sample files had chunk lengths that were multiples of 4. minimal.vrm has a single JSON chunk and no BIN chunk at all.

The VRM data lives under extensions in the JSON chunk, and that is where 0.x and 1.0 diverge:

Item	VRM 0.x	VRM 1.0
Extension name	`VRM`	`VRMC_vrm`
Model name	`meta.title`	`meta.name`
Author	`meta.author`	`meta.authors` (array)
License	`meta.licenseName`	`meta.licenseUrl`
Thumbnail	`meta.texture` = index into `textures[]`	`meta.thumbnailImage` = index into `images[]`
Expressions	`blendShapeMaster.blendShapeGroups[]`	`expressions.preset` / `expressions.custom`
Meshes	`meshes[]` (plain glTF)	`meshes[]` (plain glTF)

The thumbnail path is the sharpest difference. The 0.x schema defines texture as "Thumbnail of VRM model", and because it is a texture index you go through textures[i].source before you reach images[]. The 1.0 schema defines thumbnailImage as "The index to the thumbnail image of the model in gltf.images" (checked 2026-09-22). In 1.0, name, authors and licenseUrl are required.

vrm_dart takes neither path. It searches the images array for an entry named "Thumbnail", so any other name is a miss, and it never reads thumbnailImage at all. The third problem is casting: the generated code casts images and bufferViews to non-null lists, which is where _TypeError comes from on a file that has neither key.

I compared the two parsers on five samples. For 0.x, the CC0 add-on test fixtures minimal.vrm and triangle.vrm. There is no public 0.x sample with a thumbnail, so I built two with Blender 5.2.2 LTS and VRM add-on 4.7.1, attaching a 64×64 PNG to triangle.vrm: one with the image named "Thumbnail", one named "swas_thumb". For 1.0, VirtualCast's Seed-san.vrm.

Sample	Version	vrm_dart meta	vrm_dart thumbnail	Direct parser
minimal.vrm	0.x	`_TypeError`	`_TypeError`	meta, 17 expressions
triangle.vrm	0.x	`_TypeError`	`_TypeError`	meta, 17 expressions, 1 mesh
triangle-thumb-Thumbnail.vrm	0.x	OK	317 B	meta, thumbnail, 17 expressions, 1 mesh
triangle-thumb-swas_thumb.vrm	0.x	OK	null	meta, thumbnail, 17 expressions, 1 mesh
Seed-san.vrm	1.0	`LateInitializationError`	null	meta, thumbnail, 18 expressions, 5 meshes

vrm_dart reads exactly one row completely: the 0.x file whose image is named "Thumbnail". That is presumably the kind of file the 2024 post happened to succeed on. The direct parser reads all five. Seed-san's thumbnail came out as a 512×512 PNG of 192,765 bytes, and its meshes are hair, hair_tail, head, robo_arm and wear.

Expression names changed between versions too. The 1.0 spec's expressions document lists the renames (checked 2026-09-22), and the 17 names in the 0.x samples and 18 in the 1.0 sample match this table:

VRM 0.x	VRM 1.0	Note
joy	happy	renamed
sorrow	sad	renamed
fun	relaxed	renamed
a, i, u, e, o	aa, ih, ou, ee, oh	lip sync
blink_l, blink_r	blinkLeft, blinkRight	spelling
lookup, lookdown, lookleft, lookright	lookUp, lookDown, lookLeft, lookRight	spelling
none	surprised	new in 1.0

What to do

Read the GLB header and chunks. ByteData from dart:typed_data is enough, and the JSON chunk goes through utf8.decode then jsonDecode:

   final d = ByteData.sublistView(bytes);
   if (d.getUint32(0, Endian.little) != 0x46546C67) throw const FormatException('not a GLB');
   final length = d.getUint32(8, Endian.little);
   Map<String, dynamic>? json; Uint8List? bin;
   var off = 12;
   while (off + 8 <= length) {
     final len = d.getUint32(off, Endian.little);
     final type = d.getUint32(off + 4, Endian.little);
     final data = Uint8List.sublistView(bytes, off + 8, off + 8 + len);
     if (type == 0x4E4F534A) json = jsonDecode(utf8.decode(data)); // 'JSON'
     if (type == 0x004E4942) bin = data; // 'BIN'
     off = (off + 8 + len + 3) & ~3;
   }
   final root = json ?? (throw const FormatException('no JSON chunk'));

Tell the versions apart from extensions. VRMC_vrm present means 1.0, VRM means 0.x, and neither means it is a plain glTF, not a VRM:

   final ext = (root['extensions'] as Map<String, dynamic>?) ?? const <String, dynamic>{};
   final is10 = ext.containsKey('VRMC_vrm');
   if (!is10 && !ext.containsKey('VRM')) {
     throw const FormatException('glTF but neither VRM (0.x) nor VRMC_vrm (1.0) extension');
   }
   final v = (is10 ? ext['VRMC_vrm'] : ext['VRM']) as Map<String, dynamic>;
   final meta = v['meta'] as Map<String, dynamic>;

Read the metadata with the version's field names: title, author and licenseName for 0.x; name, authors and licenseUrl for 1.0. If a 1.0 file's creditNotation is required, the specification obliges whoever uses the model to display its credit. It does not say where or in what form, so that part is your app's decision.
Resolve the thumbnail along the two separate paths. The image bytes are a slice of the BIN chunk given by byteOffset and byteLength of bufferViews[i]:

   Uint8List bufferView(int i) {
     final bv = (root['bufferViews'] as List)[i];
     final o = (bv['byteOffset'] ?? 0) as int;
     return Uint8List.sublistView(bin!, o, o + (bv['byteLength'] as int));
   }
   int? imageIndex;
   if (is10) {
     imageIndex = meta['thumbnailImage'] as int?;
   } else if (meta['texture'] is int && meta['texture'] >= 0) {
     imageIndex = (root['textures'] as List)[meta['texture']]['source'] as int?;
   }
   final image = imageIndex == null ? null : (root['images'] as List)[imageIndex];
   final thumbnail = image?['bufferView'] == null ? null : bufferView(image['bufferView'] as int);

Walk expressions and meshes with the right keys. On 0.x it is presetName and name inside blendShapeMaster.blendShapeGroups; on 1.0 it is the keys of expressions.preset and expressions.custom. Meshes are plain glTF: name and primitives.length from meshes[].
Keep dart:io out of the parser when it goes into a Flutter package. Take a single Uint8List, so a file path, rootBundle and file_picker bytes all go through the same function. I put it into a flutter create --template=package project this way; all 4 tests passed and the dependency count added is zero.
Treat image-less files as normal. images and bufferViews may be absent, and the BIN chunk may be absent too. The code above lets all of that fall through as null.

The Blender side of this is written up separately in Blender 5.x and the VRM add-on: 5.2 LTS needs 4.4.0+, 5.3 alpha blocks even 4.7.1. The 0.x thumbnail samples in this post were built with that post's setup.

Images: both are the measurement logs (evidence/parse-glb.log and evidence/vrm-dart-legacy.log) redrawn as a table and a console view. The 1.0 sample is Seed-san by VirtualCast, Inc., under the VRM Public License 1.0.

Takeaways

Skip the package search: the VRM metadata you want is one JSON chunk behind a 12-byte header, and the only real work is branching on VRM versus VRMC_vrm. If you must keep vrm_dart, know that it only works on 0.x files whose thumbnail image is literally named "Thumbnail".

Unverified

Whether 0.x files exported by VRoid Studio or UniVRM actually name the thumbnail image "Thumbnail": the file the 2024 post read no longer exists, and this post's 0.x thumbnail samples were made with the Blender add-on.
The dart:io-free parser on mobile and web Flutter, fed through rootBundle or file_picker: I only ran flutter test on the host VM.
Malformed files whose JSON chunk is not padded to 4 bytes: all five samples were multiples of 4. The code rounds the next chunk offset up to a multiple of 4, but I did not test such a file.

Changelog

Version	Description
1.0	2024-12-03 original Korean post (partial VRM 0.x meta and thumbnail via vrm_dart)
2.0	2026-09-22 full rewrite (vrm_dart reproduced on Dart 3.13.2, zero-dependency direct parser measured on 5 samples across 0.x and 1.0, 4 flutter tests)
2.2	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Blender 5.x and the VRM add-on: 5.2 LTS needs 4.4.0+, 5.3 alpha blocks even 4.7.1 (blender_version_max is exclusive)

Ilan Kim — Tue, 22 Sep 2026 06:45:52 +0000

On Blender 5.2 LTS, VRM Addon for Blender only enables from 4.4.0 up, and on 5.3 alpha even the latest 4.7.1 refuses to enable. The cause is blender_version_max in the extension manifest, which is an exclusive bound: it names the first Blender version the extension does not support, not the last one it does. For 4.3.0 and newer, every combination the manifest gate blocks still enables through the legacy add-on zip, which has no version gate at all. The 3.9.0 line is the exception: it fails on both paths, because Blender 5.0 removed an API it imports.

This is for anyone who upgraded to Blender 5.x and found the VRM add-on missing from the panel or refusing to switch on. On 2026-09-22, on macOS Apple Silicon, I installed four add-on versions into four Blender versions two different ways and ran all 32 cells headless. The Blender builds were 5.0.1, 5.1.2, 5.2.2 LTS and 5.3.0 alpha; the add-on versions were 3.9.0, 4.3.0, 4.4.0 and 4.7.1.

The problem

Drop the 4.3.0 extension zip into Blender 5.2.2 LTS. The install reports success, and then the add-on never turns on. The console has the reason:

ERROR vrm: This Blender version (5.2.2) must be less than the maximum version (5.2.0)
Package was expected to be installed but not found: vrm

On 5.3.0 alpha the latest 4.7.1 hits the same wall, with only the version in parentheses changing to (5.3.0). Inside the app it is quieter than that: the Extensions panel shows no error, because the VRM entry is not listed at all.

Since Blender 4.2, add-ons ship as extensions, and an extension zip carries a blender_manifest.toml at its root declaring blender_version_min and blender_version_max. When those values do not match the running Blender, the files unpack fine and activation is refused.

VRM Addon for Blender publishes two zips per release:

Extension: VRM_Addon_for_Blender-Extension-4_7_1.zip
Legacy add-on: VRM_Addon_for_Blender-4_7_1.zip

The two behave differently on 5.x, and that difference is the point of this post.

What the measurements show

blender_version_max is not the last supported version. It is the first unsupported one. The manifest example in the Blender manual says so outright (checked 2026-09-22):

# Optional: Blender version that the extension does not support, earlier versions are supported.
blender_version_max = "5.1.0"

The wording of the runtime error, must be less than, means the same thing.

So 4.3.0 declaring blender_version_max = "5.2.0" is a statement that it supports up to 5.1.x. From 5.2.0 onward it is blocked whatever the patch number. The latest 4.7.1 declares 5.3.0, which covers 5.2 LTS and stops short of 5.3 alpha.

I downloaded the manifest from all 71 release tags to find the boundaries. blender_version_min is 4.2.0 on every tag. Only blender_version_max ever moved, and it moved four times:

`blender_version_max`	Add-on range	First tag	Blender it enables on
5.0.0	v3.9.0 – v3.15.0	2025-07-19	4.2 – 4.5
5.1.0	v3.16.0 – v3.21.1	2025-11-08	4.2 – 5.0
5.2.0	v3.22.0 – v4.3.3	2026-03-16	4.2 – 5.1
5.3.0	v4.4.0 – v4.7.1	2026-07-11	4.2 – 5.2 LTS

Sampling only the x.y.0 tags gets the boundaries wrong. Looking at v4.0.0 alone hid the entire 5.1.0 group of 22 tags. The "5.2 LTS needs 4.4.0 or newer" conclusion comes out of this table.

Then I checked what actually enables, across 32 cells. Each cell got a fresh BLENDER_USER_RESOURCES directory so it could not inherit state from a previous cell or from my own Blender config. O means the add-on enabled and the roundtrip passed, where the roundtrip is importing a VRM file, exporting it, and importing the export again, for both a VRM 0.x and a VRM 1.0 sample.

Extension install:

Add-on \ Blender	5.0.1	5.1.2	5.2.2 LTS	5.3.0 alpha
3.9.0	X	X	X	X
4.3.0	O	O	X	X
4.4.0	O	O	O	X
4.7.1	O	O	O	X

Legacy add-on install:

Add-on \ Blender	5.0.1	5.1.2	5.2.2 LTS	5.3.0 alpha
3.9.0	X	X	X	X
4.3.0	O	O	O	O
4.4.0	O	O	O	O
4.7.1	O	O	O	O

The legacy path has no version gate. 4.3.0 enabled on 5.2.2 and on 5.3.0 alpha and passed the roundtrip in both. That means the direct cause of the extension being refused on the spot is the manifest gate. It does not mean those combinations are free of other API incompatibilities — this run only went as far as activation plus a two-file roundtrip.

Of the four versions I tested, only the 3.9.0 line fails to activate at all. Install it the legacy way and it still raises during module load:

ImportError: cannot import name 'ShaderNodeTexPointDensity' from 'bpy.types' (unknown location)
This add-on is not compatible with Blender version 5.0 or later. Your current version is 5.2.2.

Blender 5.0 removed bpy.types.ShaderNodeTexPointDensity, 3.9.0 imports that type at module load, and the add-on carries its own guard that prints the second line. There is no install path that makes this combination work.

The silence in the Extensions panel has its own explanation. The panel queries the extensions.blender.org API filtered by Blender version, and the filtering happens server side. Ask with blender_version=5.2.2 and you get vrm 4.7.1 back; ask with 5.3.0 and there is no vrm entry in the response at all (checked 2026-09-22). The panel is not hiding an error, it is being handed an empty result.

The roundtrip passed in all 20 cells that enabled. Two samples were used: minimal.vrm for VRM 0.x, which is CC0, and VirtualCast's Seed-san.vrm for VRM 1.0, licensed under the VRM Public License 1.0. Exporting Seed-san grows it from 10,917,800 bytes to somewhere between 16,549,208 and 16,551,476 bytes — the exact figure varies slightly per combination, and all of them land near 152% of the original. I did not investigate why it grows. Whether it is related to the texture duplication issue #1114 is a separate question I have not answered.

What to do

Check your Blender version first. On 5.2 LTS you need add-on 4.4.0 or newer. On 5.0 and 5.1 the latest 4.7.1 enables fine. If you are pinned to an older add-on, read the right-hand column of the boundary table above.
If VRM is missing from the Extensions panel, grab the extension zip from the GitHub releases directly — VRM_Addon_for_Blender-Extension-<version>.zip — and use Install from Disk. The panel only ever offers the single latest version.
If the extension is refused with must be less than the maximum version, the legacy zip is a way through. Install VRM_Addon_for_Blender-<version>.zip from the same release as an add-on rather than an extension. It is also the only way to run 4.7.1 on 5.3 alpha. Be aware that this puts you outside the range the maintainer declares support for; if something breaks, moving the add-on to a version inside the supported range is the first thing to try.
The top-level folder name inside the legacy zip changes between versions. 3.9.0 unpacks to VRM_Addon_for_Blender-3_9_0, and the 4.x releases unpack to VRM_Addon_for_Blender-release. If you are enabling it from a script, discover the module with addon_utils.modules() rather than hardcoding the name.
Give up on the 3.9.0 line under 5.x. ShaderNodeTexPointDensity is gone and no install path gets around it.
If you took the legacy route, export a VRM and import it back. That roundtrip is as far as this measurement went.

Reading VRM files from a Flutter app rather than Blender is written up separately in Parsing VRM in Flutter without a package. The VRM 0.x thumbnail samples in that post were built with the 5.2.2 LTS and 4.7.1 combination from this one.

Images: both are the measurement logs (evidence/matrix-install.log) redrawn as a table and a console view.

Takeaways

Read blender_version_max as the first version that is excluded, and pick the add-on from the boundary table rather than from the panel. The legacy zip bypasses the gate, but bypassing a declared support range is a workaround, not a fix.

Unverified

Whether combinations enabled via the legacy bypass are fully functional: only the roundtrip was checked. Spring bones and the expression editing panels were not.
Windows and Linux behaviour: this ran on a single macOS Apple Silicon machine. The manifest gate is platform independent, but I could not confirm that 3.9.0 raises the same message elsewhere.
When the add-on will support Blender 5.3 after its stable release: these numbers are from 5.3.0 alpha. If blender_version_max moves to 5.4.0, the 5.3 column changes.

Changelog

Version	Description
1.0	2026-09-22 first version (Blender 5.0.1 – 5.3.0 alpha x add-on 3.9.0 – 4.7.1, 32 cells across extension and legacy installs)
1.2	2026-09-22 added the cross-link to the Flutter VRM parsing post
1.3	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Calling the NovelAI V5 API directly: nai-diffusion-5-full request body, params_version 4/3/1/0 identical, missing v4_prompt is a 500

Ilan Kim — Mon, 14 Sep 2026 01:09:22 +0000

nai-diffusion-5-full takes the same body skeleton V4 took, posted to https://image.novelai.net/ai/generate-image, and params_version — the one field every third-party tool fills in differently — returns a pixel-for-pixel identical image whether you send 4, 3, 1, or 0 with this body skeleton. JSON and multipart bodies gave the same result too. What does break it: drop either v4_prompt or v4_negative_prompt and you get 500 Internal Server Error rather than a 400, set Content-Type by hand on a FormData body and you get a missing multipart boundary 400, and post to the old host and you get a model must be a valid enum value 400.

This is for people calling NovelAI V5 from their own scripts rather than through a ComfyUI node or a GUI like NAIA (a community-built desktop front end for NovelAI). On 2026-09-14, on macOS 26.5.2 with Node v22.22.3 and an Opus account (tier: 3), I generated six images inside the free band and compared request formats, error responses, and balance changes; I also read the strings out of the official web client bundle the same day. Two terms if NovelAI is new to you: Anlas is NovelAI's generation credit, and Opus is the top subscription tier, which generates one image at a time at the common sizes and up to 28 steps without spending any, as long as no base image is involved and the allowance has not run out. The policy and the per-size cost table are in the earlier post, the measurements through a ComfyUI node are in the one after it, and this post covers only the request contract.

The problem

If you look at third-party tools' request bodies to work out how to call V5 yourself, the params_version value is different in every one of them. ComfyUI_NAIDGenerator, a ComfyUI node for NovelAI, sends 1. The README of ComfyUI_RS_NAI_API_Request, another ComfyUI node, says "V5 requests use params_version: 4 while older models keep params_version: 3". The changelog of NAIWeaver, a standalone NovelAI client, says "send params_version: 4" (all checked 2026-09-14). The official OpenAPI document has no required array and no nai-diffusion-5 string, so it cannot settle which one is right.

From there, nudging the body around gets you three responses. All three are verbatim from this round of testing:

POST https://api.novelai.net/ai/generate-image  (old host)
400 {"statusCode":400,"message":"model must be a valid enum value"}

POST https://image.novelai.net/ai/generate-image  (v4_prompt or v4_negative_prompt omitted)
500 {"statusCode":500,"message":"Internal Server Error"}

POST https://image.novelai.net/ai/generate-image  (FormData + Content-Type: multipart/form-data set by hand)
400 {"statusCode":400,"message":"missing multipart boundary"}

The first one has different wording from the "update to the image URL" 400 the balance lookup returns. The old host accepts the generation request itself but does not know the V5 model ID, so from the message alone it looks like you typed the model ID wrong.

The second is the confusing one. It is a 500 rather than a 400-class validation error, so it reads like a server outage, but the cause is your request body. The third one appears when you hand Node's fetch a FormData body and set the header yourself, because the boundary undici would have attached automatically disappears.

What the measurements show

params_version does not change the result with this body skeleton. Same prompt, seed 1234567890, 832×1216, 28 steps, one image per value:

`params_version`	Response	Response time	PNG `Source`	Anlas
4 (official web client)	200	2.5 s	`NovelAI Diffusion V5 0ADF9AB7`	9,930 → 9,930
3 (the value said to be for older models)	200	1.8 s	same	no change
1 (ComfyUI_NAIDGenerator)	200	1.9 s	same	no change
0 (a value no tool uses)	200	1.8 s	same	no change

Comparing the four images pixel by pixel with Pillow gives a mean absolute difference of 0 and 0% of pixels changed, so they are completely identical. The Comment metadata of the returned PNGs has no params_version field either. If the value were read and acted on, 0 should at least have been rejected, so with this skeleton it has to be treated as ignored. Whether that also holds for other field combinations — character prompts, inpainting and so on — I did not check.

So where does 4 come from? In the novelai.net bundle I pulled on 2026-09-14 (_app-b7172cc1a6a0b340.js), the default parameters in the nai-diffusion-5-full branch start with params_version:4, and there is migration code that raises stored settings to 4 if params_version<4. The string v5_prompt appears 0 times; v4_prompt appears twice.

The transport format makes no difference to the result either. Sending the params_version: 1 body as JSON and sending it as a JSON blob in the request part of a FormData both returned 200 with identical pixels. The debug toggle text in that same bundle describes the default as "Image generation requests will be sent as multipart form data." and the checked state as "JSON (pre-multipart-form format)", so multipart is the official client's default and JSON survives as the legacy format.

Transport	`Content-Type` handling	Response
JSON	`application/json` set explicitly	200, 917,294-byte zip
multipart	header not set (automatic boundary)	200, pixels identical to JSON
multipart	`multipart/form-data` set by hand	400 `missing multipart boundary`

You cannot leave out v4_prompt or v4_negative_prompt. With everything else left alone, a body with both keys removed, a body with only v4_prompt removed, and a body with only v4_negative_prompt removed all came back with the same 500, and none of them moved the balance. Together with the absence of v5_prompt in the bundle, I take this to mean V5 still requires the V4 structure as it is.

Authentication errors all arrive lumped into a single 401. Leave the Authorization header out entirely, or put a space inside the token value, and the response is the same 401 {"statusCode":401,"message":"Unauthorized"} either way. Since the response cannot tell you whether the token string is mangled or the header is missing, don't print the value: check its length and whether it is unchanged by trim().

For the free band, this adds the landscape size to the table in the earlier post. 1216×832 (pixel product 1,011,712) at 28 steps, one image, was also 0 Anlas, and across six generations usage.percent did not move from 87. The battery reading is an integer, which means per-image consumption below 1% is invisible in it.

I did not find an API that quotes the price up front this time. POST /ai/generate-image/request-price, which appears in the web bundle, returned 404 page not found on image.novelai.net and 404 Cannot POST /ai/generate-image/request-price on api.novelai.net. The web UI does show an estimated Anlas cost on the generate button, but I could not get the same number out of this path, and whether another path exists I could not confirm.

What to do

Use one host, https://image.novelai.net. Generation (/ai/generate-image) and balance lookup (/user/subscription) are both on it, while api.novelai.net rejects generation with model must be a valid enum value and lookups with "update to the image URL".
Use the body below as it stands. This JSON is the full body that returned 200 in the params_version: 4 row of the table above, and the prompt goes in the same string in three places: top-level input, parameters.prompt, and v4_prompt.caption.base_caption. Use 4 for params_version to match the official web client, but don't read any meaning into the value:

{
  "input": "1girl, solo, silver hair, school uniform, looking at viewer, upper body, simple background, masterpiece, best quality",
  "model": "nai-diffusion-5-full",
  "action": "generate",
  "parameters": {
    "params_version": 4,
    "width": 832, "height": 1216, "scale": 5, "sampler": "k_euler_ancestral", "steps": 28,
    "seed": 1234567890, "n_samples": 1, "ucPreset": 3, "qualityToggle": false,
    "sm": false, "sm_dyn": false, "dynamic_thresholding": false, "controlnet_strength": 1,
    "legacy": false, "add_original_image": false, "cfg_rescale": 0, "noise_schedule": "karras",
    "legacy_v3_extend": false, "uncond_scale": 1, "negative_prompt": "",
    "prompt": "1girl, solo, silver hair, school uniform, looking at viewer, upper body, simple background, masterpiece, best quality",
    "reference_image_multiple": [], "reference_information_extracted_multiple": [], "reference_strength_multiple": [],
    "extra_noise_seed": 1234567890,
    "v4_prompt": { "use_coords": false, "use_order": false, "caption": { "base_caption": "1girl, solo, silver hair, school uniform, looking at viewer, upper body, simple background, masterpiece, best quality", "char_captions": [] } },
    "v4_negative_prompt": { "use_coords": false, "use_order": false, "caption": { "base_caption": "", "char_captions": [] } }
  }
}

Save that JSON as body.json, put the file below in the same folder, and it runs as is. The key file is a text file with a pst- token on the line after a line labeled "novelai", and the token stays in memory only. Running it with node nai-v5-direct.mjs <key file> got me a 200 and an image_0.png whose pixels match the table above:

// node nai-v5-direct.mjs <key file> — the key file has a pst- token on the line after the "novelai" label
import { readFile, writeFile } from 'node:fs/promises';

const lines = (await readFile(process.argv[2], 'utf8')).split(/\r?\n/).map((l) => l.trim());
const token = lines[lines.findIndex((l) => /novelai/i.test(l)) + 1];
const body = JSON.parse(await readFile('body.json', 'utf8'));

const r = await fetch('https://image.novelai.net/ai/generate-image', {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
  body: JSON.stringify(body),
});
console.log(r.status, r.headers.get('content-type'));
if (r.ok) await writeFile('out.zip', Buffer.from(await r.arrayBuffer())); // image_0.png is inside
else console.log(await r.text());

For transport, set Content-Type: application/json explicitly if you send JSON, and do not set a Content-Type header yourself if you use FormData. Node 22's fetch builds the header with the boundary on its own for a FormData body.
The response is a binary/octet-stream zip with image_0.png inside. Check the model from the Source value in the PNG's tEXt chunk (NovelAI Diffusion V5 0ADF9AB7).
To stay at 0 Anlas, keep all of it: Opus, one image (n_samples: 1), no base image, a pixel product of 1,048,576 or less, and 28 steps or fewer — then read /user/subscription before and after the generation and compare the sum trainingStepsLeft.fixedTrainingStepsLeft + trainingStepsLeft.purchasedTrainingSteps. trainingStepsLeft is an object rather than an integer, so you cannot subtract it directly. usage.percent is too coarse to use for per-image checks.
Respect the API document's "all generation requests must be initiated by a human action" and its 429 note ("API clients should not attempt to retry") by sending human-initiated requests one at a time with a gap between them. This round of measurements ran with 6 seconds between requests and a concurrency of 1.

Image: the sample outputs in this post are AI images generated with NovelAI Diffusion V5.

Takeaways

With this body skeleton, params_version is ignored — 4, 3, 1, and 0 all return the same pixels — and JSON and multipart bodies produced the same image. The parts that actually matter are the host, image.novelai.net, and keeping both v4_prompt and v4_negative_prompt in the body, since dropping either one returns a 500 rather than a validation 400.

Unverified

How a 429 behaves: the API document explicitly forbids retrying, so I didn't provoke one on purpose. 429 isn't even documented for the image endpoints, so I don't know the actual message.
What happens when director_reference_* fields are sent to V5: V5 doesn't support Precise Reference, but the schema doesn't block these fields. Whether that is a 400 or "ignored and billed", I didn't run, because of the billing risk.
The actual charge for a 29-step or 2-image request: that is the paid band, so I didn't generate it. The price lookup path I tried was a 404, so the only figure I have is the 45 Anlas for the large size from the earlier post.
The absolute capacity of the Opus battery (allowance): usage.percent stayed fixed at 87 across six images, so I couldn't work backwards to a per-image draw.
How params_version behaves with other body skeletons: I didn't run it with character-prompt, inpainting, or img2img bodies. Large values such as 9 also fell outside the generation budget.

Changelog

Version	Description
1.0	2026-09-14 first version (macOS 26.5.2 · Node v22.22.3 · Opus, 6 free-tier generations)
1.1	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

Running NovelAI V5 in ComfyUI: nai-diffusion-5-full works, and the Error fetching Anlas 400 is a moved endpoint

Ilan Kim — Sun, 13 Sep 2026 07:59:16 +0000

nai-diffusion-5-full and nai-diffusion-5-curated work as they are through the ComfyUI_NAIDGenerator node, even though the README says the IDs haven't been checked against the live API. The Error fetching Anlas 400 that shows up next to them has nothing to do with the models: the node still asks https://api.novelai.net/user/data for your balance, and NovelAI moved its user endpoints to image.novelai.net, so two spots in nodes.py fix it.

Overview

The Source metadata in the PNGs the node brought back read NovelAI Diffusion V5 0ADF9AB7 and NovelAI Diffusion V5 DB276663 respectively, and on an Opus account one image at Normal size (832×1216) and 28 steps cost 0 Anlas. Two terms if NovelAI is new to you: Anlas is NovelAI's generation credit, and Opus is the top subscription tier, which generates the common sizes without spending any.

I wrote this for people who read the README line "have not been independently confirmed against the live API yet" and hesitated, and for anyone hitting Error fetching Anlas the way issue #51 describes. I installed ComfyUI v0.35.0 fresh on macOS and pinned the node to its 2026-08-21 commit, 52da75a (package version 1.0.9).

The problem

Wire the Anlas Tracker node into Preview Any and run it, and the preview text reads Error fetching Anlas while the console prints one line:

[NovelAI] Failed to fetch Anlas balance: 400 Client Error: Bad Request for url: https://api.novelai.net/user/data

The node added the two V5 model IDs in PR #50 on 2026-08-21, but the README still carries the caveat that they were never compared against the live API. Issue #51, opened the next day, reports a generation 400 on a trial account together with Error fetching Anlas, and as of 2026-09-13 it has no replies.

Meanwhile NovelAI moved its user endpoints to image.novelai.net around the V5 launch. The 400 from the old host is exactly what I saw in my earlier Korean post, so I checked whether the node was failing for the same reason.

The cause

It is because _get_user_data in nodes.py calls /user/data with USER_API_BASE_URL = "https://api.novelai.net". Attach a token and call both hosts directly, and their answers diverge:

Call	Response
`GET https://api.novelai.net/user/data`	400 `{"statusCode":400,"message":"Please refresh NovelAI.net. If using a third-party tool, update to the image URL."}`
`GET https://image.novelai.net/user/data`	200, includes `subscription.trainingStepsLeft`

Without a token both hosts return 401, so reproducing this needs a valid one. Swapping the host isn't the end of it either. On the new host trainingStepsLeft is not an integer but a shape like {"fixedTrainingStepsLeft": 9898, "purchasedTrainingSteps": 32}, so the Tracker text prints the dictionary verbatim and the Generate node's before-and-after subtraction start_anlas - final_anlas dies with TypeError: unsupported operand type(s) for -: 'dict' and 'dict'.

The model IDs themselves were fine. Here is what a ModelOption → Generate → Save Image workflow returned over POST /prompt, with the same prompt, seed, and 28 steps as the earlier post:

Model	Size	Result	PNG `Source`	Subscription Anlas
`nai-diffusion-5-full`	832×1216	200, 4.1 s	`NovelAI Diffusion V5 0ADF9AB7`	9,898 → 9,898
`nai-diffusion-5-curated`	512×768	200, 1.6 s	`NovelAI Diffusion V5 DB276663`	9,898 → 9,898

There is one trap. The PNG that Save Image writes keeps only the prompt chunk, and the Source field NovelAI set is gone. The node saves the original separately under a running number such as output/NAI_autosave_00001_.png, so read the metadata from the file whose number matches the run you just made.

What to do

Fix _get_user_data in nodes.py in two places. Point the host at image.novelai.net, and normalize the dictionary-shaped trainingStepsLeft into an integer total:

-    USER_API_BASE_URL = "https://api.novelai.net"
+    USER_API_BASE_URL = "https://image.novelai.net"
@@
     response.raise_for_status()
-    return response.json()
+    data = response.json()
+    steps = data.get("subscription", {}).get("trainingStepsLeft")
+    if isinstance(steps, dict):
+        data["subscription"]["trainingStepsLeft"] = int(steps.get("fixedTrainingStepsLeft", 0) or 0) + int(steps.get("purchasedTrainingSteps", 0) or 0)
+    return data

Restart the server and run the Anlas Tracker again, and it shows 9930 Anlas. That is the subscription 9,898 plus the purchased 32, the same number the web UI shows as your total, and when I generated one more V5 image at Normal size after the patch, the console printed Generation cost: 0 Anlas.
For V5, picking nai-diffusion-5-full in ModelOption is all there is to it. On Opus, leave limit_opus_free on and Normal size at 28 steps or fewer stays in the free band.
I sent the same patch upstream as PR #52, along with a correction to the unconfirmed line in the README. I also posted the reproduction log on issue #51 with a link to this article.

Image: the sample output was generated with NovelAI Diffusion V5.

Takeaways

Both V5 model IDs work through the node as shipped, and the Error fetching Anlas 400 is the balance lookup still pointing at api.novelai.net. Fixing it takes the new host plus one normalization, because trainingStepsLeft now arrives as a dictionary rather than an integer.

Unverified

The generation 400 on a trial account: I don't have a trial account, so I couldn't reproduce the generation failure from issue #51. Whether it shares a cause with the balance lookup failure, I don't know.
Regression on V4.5 and older models: I judged from the code alone that the patch touches only the balance lookup function and leaves the generation path alone, and I did not re-run a V4.5 generation.

Changelog

Version	Description
1.0	2026-09-13 first written (ComfyUI 0.35.0 + ComfyUI_NAIDGenerator 52da75a, measured on an Opus account)
1.1	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

NovelAI V5 on Opus: usage limits, the 2026-09-21 subscription Anlas reset, and the api.novelai.net to image.novelai.net move

Ilan Kim — Fri, 11 Sep 2026 17:28:39 +0000

On an Opus account (NovelAI's top subscription tier), NovelAI Diffusion V5 still costs 0 Anlas (NovelAI's generation credits) up to Normal size (832×1216) at 28 steps and one image per request; Large (1024×1536) is where 45 Anlas starts coming out of your balance. From September 21, 2026, your unused subscription Anlas resets to 0 when your subscription period ends, and the balance endpoint has moved from api.novelai.net to image.novelai.net. The reset is tied to the end of your period, not to the effective date: on September 22, the day after it took effect, this account's balance was still untouched.

Overview

V5 shipped on 2026-08-21, and with it came a "battery" usage limit on Opus subscriptions. The announcement doesn't say how much a single generation draws or where you can see it, so I ran the numbers myself against the API. The reset itself is still a policy statement here: this account's paid period runs to September 29, so the day-after query only shows that nothing is wiped on the effective date. I measured on 2026-09-11 and 2026-09-13, and queried once more on 2026-09-22.

I wrote this for two groups: people deciding whether to keep or cancel Opus, and people driving the NovelAI API directly from tools like ComfyUI nodes. In that order: the per-size cost table, the new usage field, and the endpoint that moved.

The problem

Querying your balance at the old address now returns a 400. The response body is a single line:

GET https://api.novelai.net/user/subscription → 400
{"statusCode":400,"message":"Please refresh NovelAI.net. If using a third-party tool, update to the image URL."}

On top of that there's a policy change. The official blog post (2026-08-20) says a rechargeable battery-style usage limit applies to V5 only, refilling automatically over roughly a week, and that starting 31 days after the V5 release, unused subscription Anlas is reset to 0 when a subscription period ends. V5 launched on August 21, which puts the effective date at September 21.

Image models older than V5 and the text models stay unlimited. But Anlas was visibly draining on an Opus account while generating with V5, so I needed to find out under exactly which conditions it gets charged.

What I measured

On an Opus account (tier: 3) I generated one image at a time with the same prompt, seed, and 28 steps, calling GET https://image.novelai.net/user/subscription before and after each generation and diffing trainingStepsLeft. Balance queries have to go to that host now to get a normal response.

Model	Size	Anlas charged
`nai-diffusion-5-full`	512×768 (Small)	0
`nai-diffusion-5-full`	832×1216 (Normal)	0
`nai-diffusion-5-full`	1024×1536 (Large)	45
`nai-diffusion-4-5-full`	832×1216 (Normal)	0
`nai-diffusion-5-curated`	512×768 (Small)	0

Within what I measured, everything up to Normal size (832×1216) at 28 steps and one image per request was 0 Anlas, and subscription Anlas started coming out at Large (1024×1536). The ComfyUI node (ComfyUI_NAIDGenerator) implements the Opus free tier as up to 1,048,576 pixels (1024×1024), up to 28 steps, and one image — I didn't measure 29 steps, multi-image batches, or the exact pixel boundary this time. Large size is where subscription Anlas gets charged, and that subscription Anlas (fixedTrainingStepsLeft) is what disappears when your subscription period ends after September 21. If you only cancel renewal and still have paid time left, the clock is the end of that paid period.

I queried the same account again once the effective date had passed. On 2026-09-22 the subscription Anlas read 9,898, the same figure as the September 13 sample, and expiresAt was still 1790674321, which is 2026-09-29 18:32 KST. So at least on this account nothing was wiped on the effective date; it is simply still inside its paid period. That is one sample, but it rules out a blanket reset on the day itself. I'll query again after that renewal and report what the reset does.

The test account held 9,961 subscription Anlas and 32 purchased Anlas (purchasedTrainingSteps) as separate line items, and the 45 for the Large generation came out of subscription Anlas only (9,961 → 9,916). If the total the web UI shows doesn't match, check whether it's the sum of the two. The reset targets the subscription side; whether purchased Anlas is exempt is listed under Unverified below.

The battery sits at the end of the subscription response, in a usage field. It didn't move once across four V5 generations. When I queried again 46 hours later, percent had dropped to 98 — after a handful of additional V5 generations from the web UI on this account in between (count not recorded). So the battery is a meter that really does go down, and timeUntilNextPercent stayed at 7,888 even at 98%, so it isn't a live countdown. A third sample nine days later was back at 100%, so it does recharge, but September 19 — the date NovelAI's official account gave for the usage limit renewal, seen 2026-09-14 — falls inside that gap, so I can't tell natural recharge from the renewal. timeUntilNextPercent read 7,888 in all three samples. That's as far as the evidence goes:

"usage": {
  "percent": 100,
  "isNegative": false,
  "timeUntilNextPercent": 7888
}

I checked the V5 model IDs while I was there. Both nai-diffusion-5-full and nai-diffusion-5-curated returned 200 with an image, and the PNG Source metadata read NovelAI Diffusion V5 0ADF9AB7 and NovelAI Diffusion V5 DB276663 respectively. Sending an ID that doesn't exist returns Validation error: model nai-diffusion-5-nonexistent doesn't exist.

For reference, a Japanese write-up (note.com, 2026-08-21) put V5 generation cost at 11 Anlas for Small, 26 for Normal, and 39 for Large, while my measurement for Large was 45. That write-up doesn't state step count or account tier (the web UI default is 23 steps; my runs were 28), so it isn't directly comparable. Logged out, the web UI showed 26 Anlas for the default settings (V5 Curated, 23 steps, Normal size), which is the non-subscriber rate with no free tier.

What to do

Keeping Opus doesn't exempt you from the V5 battery usage limit. That said, within what I measured, the Anlas charging rules are the same as V4.5 — up to Normal size, 28 steps or fewer, one image at a time, it's 0 Anlas. Battery capacity and recharge rate are still unknown. A second sample 46 hours later showed 98%, but I didn't record how many images were generated in between, so how much use it takes to get blocked stays unverified.
If you plan to cancel, order matters. After September 21, whatever subscription Anlas is left disappears when your subscription period ends, so it's better to burn the subscription side down before that period runs out — with Large generations or multi-image batches.
In third-party tools, point the balance query at image.novelai.net. If generation works but the balance won't load, that's almost always this.

Image: the sample output was generated with NovelAI Diffusion V5.

Takeaways

On Opus, V5 is still free up to Normal size at 28 steps, and if you plan to cancel, spend down your subscription Anlas before your paid period ends once the reset policy takes effect on September 21, 2026. If a tool can generate but can't read your balance, the old host is the most likely cause, so check which balance endpoint it calls.

Unverified

How the subscription Anlas reset actually behaves: the effective date has passed, but this account still has paid time left, so there was nothing to observe. I'll re-query after its renewal on 2026-09-29.
Battery capacity and recharge rate: three samples show it going down and coming back up, but the generations in between weren't counted and the September 19 renewal falls inside the gap, so I couldn't derive a drain or recharge rate.
The reset notice text and battery display in the web UI: my browser session was logged out, so I couldn't capture the subscriber view.
Whether purchased Anlas is exempt from the reset: inferred from the official post mentioning subscription Anlas only.

Changelog

Version	Description
1.0	2026-09-11 first written (measured on an Opus account via API)
1.1	2026-09-13 second battery sample added (re-queried 46 hours later)
1.2	2026-09-22 re-queried the day after the effective date (subscription Anlas unchanged at 9,898, battery back at 100%)
1.3	2026-09-30 added the AI disclosure line (no content change)

AI disclosure: translated and edited with AI assistance (Claude) from my Korean original. Measurements were run with Claude Code under my supervision; I reviewed the result.

DEV Community: Ilan Kim

sshole CVE-2026-123158 on Alpine: ssh -V can't tell you if it's patched, so check the package revision and restart sshd

All four conditions must hold for CVE-2026-123158 to apply

These setups are not affected

Same ssh -V, different patch state: the revision decides

No usepam line in sshd -T means a build without PAM

One read-only script gives the verdict

After the package upgrade, restart sshd or you aren't done

If you can't upgrade yet, block it with PasswordAuthentication no

Check Accepted password for lines first to see if you were hit

Takeaways

Unverified

Changelog

NIKKE PC launcher hack: was my PC infected? k2f_chan in debug.log, 4 traces to check, accounts to rotate (2026-11-04)

k2f_chan in NIKKE's debug.log means your PC was infected

Running the launcher in that window doesn't mean you were infected

The NIKKE PC launcher hack started with tampering on September 27

A read-only script checks all four traces at once

If you're infected, remove things in this order

Deleting the traces doesn't bring back leaked accounts and API keys

Takeaways

Unverified

Changelog

SillyTavern remote access security checklist: 11 CVEs in 2026, the Node Brotli fix (CVE-2026-111497), 6 config.yaml keys

Without access control, SillyTavern refuses to start with listen: true

All 11 SillyTavern CVEs of 2026 are fixed in 1.18.0

Node2Shell (CVE-2026-111497) reaches SillyTavern through the responses it fetches

process.versions.brotli can't tell you whether you're patched

The official Docker image latest ships Node 24.21.0 as of 2026-10-28

Check two versions, six settings and one log, in that order

1. Check the SillyTavern version

2. Check Node

3. Update Node

4. Update SillyTavern to 1.19.0

5. Check six config.yaml entries

6. If an LLM server runs elsewhere on your LAN, add its range to allowedRanges

7. Check the logs

Takeaways

Unverified

Changelog

ComfyUI MCP servers compared: comfyui-mcp, comfy-mcp and comfyui-mcp-secure in Claude Code, measured for ports, paths, tokens

comfyui-mcp, comfy-mcp and comfyui-mcp-secure aim at different things

With the default stdio transport, none of the three opens a port

comfyui-mcp and comfy-mcp read and write outside ComfyUI, even on the Desktop

comfyui-mcp has the heaviest tool definitions at 77.3k tokens

Install size differs tenfold: 851MB versus 82MB

comfyui-mcp reached the first image fastest: 12 seconds, 4 tool calls

An MCP server security checklist in four steps

First, check whether your setup is affected

Pin patches and versions

Narrow the settings

Check for traces

Which server to pick depends on how you work

Takeaways

Unverified

Changelog

NovelAI V5 upscaling measured: Enhance at 35 and 45 Anlas vs ComfyUI Anima i2i, and how much the style shifts (ΔE)

Enhance 1.5× cost 35 Anlas, Max cost 45 Anlas

Enhance output records a strength 0.5 i2i request

Enhance changed the image more than Anima i2i at 0.55

In the two-character image, Enhance kept the eye color and Anima changed it

Sign lettering was rewritten by every i2i pass

Local ComfyUI post-processing on an RTX 5090: 2 to 38 seconds per image, 0 Anlas

Stealth metadata disappears on a ComfyUI save but survives webp

Choose by how much of the original you want to keep

Takeaways

Unverified

Changelog

Crack cash payouts: the 8.8% is other-income tax, not a fee — what you receive, May filing, business registration

The 8.8% is withholding tax on other income

Converting KRW 1,000,000 puts KRW 912,000 in your account

Cash-out starts at KRW 10,000 and pays on the 10th and 25th of each month

Conversions of KRW 125,000 or less are not taxed under the statute

Cash saved over several months is reported in one lump on the payment date

Crack's 8.8% and May income tax: at KRW 3,000,000 of other-income amount or less, you can choose separate taxation

If you have a salary, combining costs you more from the 24% marginal bracket up

Creators paid out every month should check the business registration test

Health insurance dependents: KRW 20,000,000 a year; dependent tax deduction: KRW 1,000,000 of income amount

Finding the withholding record for Crack payouts on Hometax

Checklist before you convert your cash

5. Check six `config.yaml` entries

6. If an LLM server runs elsewhere on your LAN, add its range to `allowedRanges`