<div dir="ltr"><div><div dir="auto">Hi Salvatore,<br><br>Sorry about that: my previous mail went out in Gmail confidential mode, so<br>it did not reach the bug log in readable form. Here it is again as plain<br>mail, with the patch attached.<br><br>A patch for both CVEs is attached. Upstream is archived and marked end of<br>life, so there is no upstream fix to pull; this is a Debian-side change.<br><br>Root cause<br>----------<br>nm-vpnc-service serialises VPN settings into vpnc's line-oriented config.<br>validate_one_property() rejects newline and carriage return, but only in<br>the ITEM_TYPE_STRING and ITEM_TYPE_SECRET branches (the 1.2.6 fix for<br>CVE-2018-10900). Two values reach the writer without that check:<br><br>- CA-File (ITEM_TYPE_PATH): its branch checks only that the path is<br>  non-empty, absolute and existing. A newline in the path splits into<br>  extra vpnc directives. This is CVE-2026-91841, described upstream as an<br>  incomplete fix of CVE-2018-10900.<br><br>- The top-level NMSettingVpn:user-name: nm_vpnc_properties_validate()<br>  walks the data items and the secrets, but not the connection's<br>  user-name, which nm_vpnc_config_write() writes out as "Xauth username".<br>  This is CVE-2026-91840.<br><br>A newline in either value injects directives such as "Password helper",<br>which vpnc runs as root during the xauth exchange, so an unprivileged<br>local user who can activate a private profile gets root. The reporter's<br>writeup in the two upstream issues has the full chain.<br><br>I confirmed both gaps by reading the source of 1.2.8-4 (bookworm), 1.4.0-2<br>(trixie) and 1.4.0-4 (sid/forky): in all three the ITEM_TYPE_PATH branch<br>has no newline check, and the user-name is written without validation.<br><br>The patch<br>---------<br>It adds the missing newline rejection to the ITEM_TYPE_PATH branch and<br>validates the top-level user-name in nm_vpnc_properties_validate(), using<br>the same strchr check the STRING/SECRET branch already uses. The attached<br>patch is one file (src/nm-vpnc-service.c). It applies cleanly to 1.4.0-2<br>and 1.4.0-4, and with a -3 line offset to 1.2.8-4.<br><br>What I did and did not test<br>---------------------------<br>The patched source compiles cleanly (no warnings in the file) against the<br>libnm and glib headers, for both the 1.2.8 and 1.4.0 trees. I did not run<br>a full package build: automake and some of the -dev build-dependencies<br>are not currently installable here. I also did not build an exploit to<br>demonstrate the escalation; the fix mirrors the existing, already-accepted<br>CVE-2018-10900 rejection in the same function, and legitimate paths and<br>user names contain no newlines.<br><br>Given that upstream is EOL and GNOME's advisory recommends migrating away<br>from this plugin, you may prefer to remove the package rather than carry a<br>patch. Either way the tracker entries have no fix reference, and this at<br>least gives a minimal one if you keep the package.<br><br>Regards,<br>Sumit Verma</div></div></div>