oauthlib 4.0.1 shipped on Saturday with the device-flow fix that GitHub's database, and this digest yesterday, credited to 4.0.0. If you run an OAuth server on oauthlib with the device grant turned on, upgrade and implement the new validator hook. Your scanner will tell you 4.0.0 is fine, and it isn't.

Only the oauthlib record carries a package in GitHub's database, and it names the wrong fix. fickling's, Presenton's and DeepInfer's CVEs are unreviewed records with no package, so a scanner raises none of them.

Worth your morning

oauthlib: the fix is in 4.0.1, and the database says 4.0.0. GHSA-3jp2 (CVE-2026-49272, 8.5) covers OAuth servers built on oauthlib's RFC 8628 device grant. From 3.3.0, the token endpoint didn't validate the device_code parameter, so a request with a known client ID and a made-up device code could get a bearer token. The maintainers' advisory has named 4.0.1 since October 23, and that release reached PyPI on Saturday at 09:52 UTC. GitHub's reviewed record (October 27) says < 4.0.0, fixed in 4.0.0. But 4.0.0 (September 28) has no device-code check: the hook doesn't exist at that tag, and 4.0.1's device grant calls it. This digest repeated the 4.0.0 claim yesterday. It was wrong.

The fix comes with work for the integrator. 4.0.1 adds validate_device_code() to the request validator, and its default raises NotImplementedError, so a provider using the device flow has to implement it against its own store of codes, or device-flow token requests fail after the upgrade. django-oauth-toolkit offers the device grant and accepts any oauthlib from 3.3.0, but neither its 3.4.1 release nor its master branch defines the hook yet; test device-flow token requests before you roll 4.0.1 out. Client-side users of requests-oauthlib aren't the exposure. oauthlib is installed 64 million times a week.

fickling: a second 8.8, the same unreleased fix. CVE-2026-16760 (VulnCheck, 8.8 on v3.1) arrived on Friday night in the same minute as CVE-2026-118938, which yesterday's digest covered; this one it missed. Same versions (through 0.1.12), same cited commit. fickling treated any name imported from a standard-library module that wasn't on its denylist as likely safe, and a later pass skipped calls to those names, so a crafted pickle could come back as safe. #340 (Friday) and #343 (Saturday, which reworks the standard-library import analysis) are on master, 41 commits past v0.1.12 (June 26). No release carries them, and the project hasn't published an advisory for either CVE. Treat fickling's verdict as one signal among several, and load weights from outside as safetensors where you can.

DeepInfer: off by default, open when on. DeepSeek's inference framework (0.1.0 on PyPI since October 20, 24,700 stars) has a runtime profiling API that the engine starts only when DEEPINFER_PROFILE_HTTP_ENABLE=1 is set. When it is, the server listens on every interface at port 6070 plus the GPU index, with no authentication. CVE-2026-120204 (VulnCheck, 5.6 on v3.1, 6.3 on v4) says the endpoint takes an output directory from the request: a caller can create directories and write trace files outside the intended path, fill the disk, and use error messages to learn what exists on the filesystem. The CVE adds that a web page open in the operator's browser can send the request. PR 242, which hardens the server, has been open since Tuesday, and 0.1.0 is the only release. Leave the variable unset in production. If you need to profile, do it on a host whose 6070-range ports nothing else can reach, and switch it off afterwards.

Presenton: the desktop app's local services had no login. Two VulDB records published this morning cover the desktop app of the open-source AI presentation generator (11,600 stars) up to 0.9.11-beta. CVE-2026-120191 (7.3 on v3.1) says its local API answered without authentication; CVE-2026-120192 (5.3) says a route served the app's credential database and logs. The reports were filed on October 3, the fix (PR 980) merged on October 12, and 0.9.12-beta, which adds desktop authentication, shipped on Monday. Upgrade the desktop app. If it ran on a shared machine, rotate the provider API keys you stored in it.

Also on the AI stack.

• ramparts 0.8.1 through 0.8.10 (CVE-2026-120202, 6.5 on v3.1, 7.1 on v4): Highflame's MCP and agent-skill scanner doesn't inspect compiled Python files in nested folders of a skill bundle, so a bundle can carry code the scan never sees and Python runs anyway. 0.8.10 (October 1) is the newest release, and the report has been open since Friday. It's small (98 stars, about 4,100 downloads on crates.io), but it's the second scanner today that can call a bad file clean.
• LobeChat 2.3.0 (this morning, 09:12 UTC) lists one security fix with no advisory: its built-in OIDC provider now pins the request host to APP_URL instead of taking it from the incoming request (#21985). If you self-host with the OIDC provider in use, upgrade.

Quiet elsewhere. GitHub's reviewed feed has published nothing since Friday 23:13 UTC; the same query for Wednesday and Thursday returns 117 records, so the zero is the weekend, not the query. The overnight unreviewed batches were mostly WordPress plugins, and Gitea's twenty CVEs this morning are outside both lists. MSRC's overnight revisions touched only Chromium, Linux and other open-source package entries; no .NET, ASP.NET Core, Visual Studio or Azure record moved, and Angular and PrimeNG released nothing.

Standing items. LMDeploy's PR 4964 is still open and 0.18.0 is still the newest release. Nothing has touched n8n's Databricks node since October 28. Open WebUI still hasn't published the advisories promised for 0.12.5. node-forge's six remaining records, both signature forgeries among them, still aren't in GitHub's database. Agno, mcp-remote, MLflow and Langflow are unchanged.