Catch-Up Bulletin, September 13 to September 25, 2026: anyio TLS Spoofing Reaches Dependabot, Unauthenticated RCE in LMDeploy, and a Developer-Workstation Cluster in Amazon Q, Cline, and Rsdoctor

This bulletin covers the thirteen days since the September 12 catch-up, and it is a narrower edition than usual for a reason stated plainly in the framing note below. The lead is anyio CVE-2026-63374 (CVSS 9.3): a TLS certificate spoofing flaw in the async library that sits underneath FastAPI, Starlette, and httpx, fixed in 4.14.2 back on July 12 but only entered into the GitHub Advisory Database on September 18, which means Dependabot and other GitHub-native scanners started flagging it during this window rather than in July. Next is LMDeploy CVE-2025-66455 (CVSS 9.8), an unauthenticated pickle-deserialization RCE in the DistServe disaggregation endpoint of a widely deployed LLM serving stack, advisory published September 16 and fixed in 0.16.0. A cluster of developer-workstation bugs landed together on September 24: Amazon Q's language server (CVE-2026-12957) runs workspace-defined commands when you open a crafted project and trust it, Cline (CVE-2026-59723) exposes its local dashboard to any website the developer visits, and Rsdoctor (CVE-2026-61782) serves your full build source over an unauthenticated API bound to all interfaces. Two MCP servers shipped authentication failures: mcp-atlassian (CVE-2026-77244, CVSS 10.0) accepted any non-empty bearer token, and @bytebase/dbhub (CVE-2026-61742) fell to DNS rebinding. Also inside: Podman leaking host environment variables to malicious images, a RabbitMQ Go client parser desynchronization, and a short roll-up of ZITADEL, OpenBao, hpack, and others. If you do nothing else: pin anyio to 4.14.2 or later in every Python lockfile, upgrade LMDeploy and get its DistServe endpoint off any reachable interface, and update the developer tooling on your workstations.

Framing note, and an unusual scope limitation: this edition was prepared in a build environment whose network policy blocked almost every source this project normally relies on. cisa.gov was unreachable, so the KEV catalog was not consulted and no item here carries a KEV claim. Every vendor PSIRT (Palo Alto, Fortinet, SolarWinds, Microsoft, Cisco), every named research team's blog (watchTowr, Wiz, Socket, StepSecurity, Aikido, Unit 42), NVD, CVE.org, OSV, and every news aggregator were also blocked. What remained reachable, and what every claim below is therefore sourced to, is the GitHub Advisory Database, the npm and PyPI registries, and the Go module proxy. The consequence is that this bulletin covers the dependency and developer-tooling surface only. It does not cover edge appliances, Patch Tuesday, or actively exploited vendor products for this window, and it should not be read as a statement that nothing happened there. Search-index summaries reaching this environment referenced activity involving Palo Alto, Fortinet, SolarWinds, Microsoft and the KEV catalog in this window. Their specifics are not reproduced here beyond the vendor names, because the same index was separately caught conflating 2025 and 2026 incidents; none of the underlying primaries could be fetched, so this bulletin makes no factual claim about any of it and gives no versions, CVE ids or counts. Check your own vendor feeds for that half of the window. Items below are ordered by breadth of exposure for developers, ops, AI/ML infrastructure operators, and self-hosters, not by CVSS. All "as of" statements are anchored to September 25, 2026, and registry and module-proxy state was checked live on that date.

Priorities, by what you run

The table maps each item to who needs to act. "Higher" means broad footprint in this audience with a fix already available and a plausible path from ordinary behavior to compromise; "Medium" means a real fix to apply on your normal cadence, or a narrower footprint; "Lower" means awareness or a niche check. No item in this edition carries confirmed in-the-wild exploitation, because the sources that would establish that were unreachable; the ordering is this bulletin's own judgment of exposure breadth.

Prioritization is this bulletin's own, based on how many readers in this audience are likely to be running each component and how ordinary the triggering action is. It is not a vendor urgency rating, and because CISA KEV was unreachable this cycle it does not reflect exploitation status for any item.

1. anyio: TLS certificate spoofing for internationalized domains, fixed in July, surfaced to your tooling in September (CVE-2026-63374)

The GitHub Advisory Database reviewed and published GHSA-82r6-8w77-94w6 on September 18, 2026, for a vulnerability whose advisory carries a publication date of July 7, 2026 and whose fix shipped in anyio 4.14.2 on July 12. That gap is the operator story here. anyio is the async compatibility layer underneath a large share of the modern Python web stack: Starlette and therefore FastAPI depend on it, as do httpx and httpcore. Very few teams declare it directly, so it sits in the lockfile unnoticed until a scanner names it, and for most teams the scanner only started naming it during this window.

The flaw itself is an improper certificate validation issue (CWE-295 and CWE-297) rated CVSS 9.3 under CVSS v4, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N. Services reached by internationalized (non-ASCII) domain names are the affected set. anyio encoded host names using IDNA 2003 rather than IDNA 2008 when establishing TLS through connect_tcp() or TLSStream.wrap(). The two standards disagree about how certain characters map, so an attacker who can obtain a legitimate certificate for the IDNA 2003 encoding of a name, and who can redirect the connection, can present that certificate and have it validate. The practical read: this needs an internationalized domain and a network position, which makes it narrower in exploitation than its score suggests, but the population running a vulnerable anyio is close to everyone shipping Python services, and the upgrade is cheap.

Am I affected?

# what is actually installed in the current environment
python3 -c "
from importlib.metadata import version, PackageNotFoundError
for p, fix in {'anyio':'4.14.2','hpack':'4.2.0','lmdeploy':'0.16.0','mcp-atlassian':'0.22.0'}.items():
    try: print(f'{p}: installed {version(p)}, fixed in {fix}')
    except PackageNotFoundError: print(f'{p}: not installed')
"

# who pulled it in
pip show anyio 2>/dev/null | grep -E '^(Version|Required-by)'

# pinned versions across requirements files (*.txt, so requirements/base.txt
# and constraints files are covered too, not just ./requirements*.txt)
grep -rEn '^[[:space:]]*(anyio|hpack|lmdeploy|mcp-atlassian)[=<>~!]' --include='*.txt' .

# poetry.lock and uv.lock are TOML: name and version sit on adjacent lines
grep -rEn -A1 'name = "(anyio|hpack|lmdeploy|mcp-atlassian)"' --include='*.lock' .

# Pipfile.lock is JSON, not TOML, so the pattern above never matches it
grep -rEn '"(anyio|hpack|lmdeploy|mcp-atlassian)":' --include='Pipfile.lock' .

The importlib.metadata check is the authoritative one for a running service, because it reads what the interpreter would actually import rather than what a file says should be there. Run it inside the container or virtualenv the service uses, not on the host. The Required-by line from pip show tells you which of your direct dependencies is holding anyio back if the upgrade does not take.

Response

1. Raise the floor in the lockfile, not the import site. Add an explicit constraint of anyio>=4.14.2 and re-resolve. Because anyio is transitive, bumping your direct dependency (FastAPI, httpx) may or may not move it, depending on what else pins it; an explicit constraint is deterministic and can be removed later. Rebuild and redeploy your images: a lockfile change that never reaches a running container has fixed nothing.
2. Decide whether you actually connect to internationalized domains. If every outbound TLS destination your service uses is an ASCII hostname you control or pin, your real exposure is low and this can ride your normal release train. If your service takes a hostname from user input, a webhook target, or a tenant configuration, treat it as the higher-priority item the table says it is, because you do not control the character set.
3. If you cannot upgrade, encode host names before connecting. The advisory's own workaround is to pass host names through the idna package (which implements IDNA 2008) before handing them to connect_tcp() or TLSStream.wrap(). This is a code change at every call site, so it is a stopgap for a service you cannot redeploy quickly, not a substitute for the upgrade.

2. LMDeploy: unauthenticated pickle deserialization to RCE in the DistServe endpoint (CVE-2025-66455, advisory published September 16)

GHSA-2vh9-42vm-xmv2 was published on September 16, 2026, inside this window, and is the most directly dangerous item in this edition for anyone running model-serving infrastructure. LMDeploy's PyTorch DistServe disaggregation feature exposed /distserve/p2p_connect on its API server. The handler in lmdeploy/pytorch/disagg/conn/engine_conn.py used PyZMQ's recv_pyobj(), which is Python pickle deserialization, and pickle executes arbitrary code during object reconstruction by design. An attacker who can reach that HTTP endpoint supplies a ZeroMQ address they control, LMDeploy connects out to it, and the crafted payload it receives runs as the serving process. No authentication is required unless you explicitly configured an API key. The advisory rates it CVSS 9.8.

What makes this worse than a generic RCE is what the LMDeploy process sits next to: model weights, inbound prompts and their contents, whatever inference API keys the process holds, the storage it has mounted, and GPU resources that are attractive in their own right. The fix in 0.16.0 replaced pickle with JSON plus Pydantic schema validation, which is the correct structural remedy rather than a filter.

Am I affected?

# installed version, inside the serving container
python3 -c "
from importlib.metadata import version, PackageNotFoundError
try: print('lmdeploy', version('lmdeploy'))
except PackageNotFoundError: print('lmdeploy not installed')
"

# is the DistServe API server listening, and on what interface?
ss -lntp 2>/dev/null | grep -E ':23333\b'   || lsof -nP -iTCP -sTCP:LISTEN 2>/dev/null | grep -E ':23333'

# Anything bound to all interfaces is the finding, not the port number itself.
# ss prints a dual-stack wildcard bind as *:PORT or [::]:PORT, so matching only
# 0.0.0.0 would silently pass exactly the exposed configuration:
ss -lntp 2>/dev/null | grep -E '(0\.0\.0\.0|\*|\[::\]):23333\b'
# ... or just list every non-loopback listener and recognise your own:
ss -lntpH 2>/dev/null | grep -vE '127\.0\.0\.1:|\[::1\]:'

# does this build still carry the vulnerable call?
python3 -c "import lmdeploy, os; print(os.path.dirname(lmdeploy.__file__))" 2>/dev/null \
  | xargs -I{} grep -rn 'recv_pyobj' {}/pytorch/disagg/ 2>/dev/null

23333 is LMDeploy's default API server port; adjust for your own --server-port. On macOS there is no ss and no /proc, so use the lsof alternative given above. The recv_pyobj grep is the most reliable check if you are running a build from source, a fork, or a vendored copy where the version string does not tell you what is in the file. A hit in pytorch/disagg/ means you are on vulnerable code regardless of what the metadata says.

Response

1. Take the endpoint off any interface that is not your control plane, first. This comes before the upgrade because it is the one you can do in minutes, and because upgrading restarts the serving process, which destroys the volatile state step 2 depends on. Bind the API server to localhost or a private interface and put your reverse proxy or service mesh in front of it, and confirm that no security group, ingress, or host firewall rule exposes the port more broadly than you assumed. An inference server on 0.0.0.0 inside a flat cluster network is reachable by every workload in that cluster.
2. If the endpoint was exposed, establish that before you upgrade. Execution is as the serving process, so the credentials to rotate are the ones that process could read: inference provider keys, object storage credentials for the weights bucket, any cloud instance role, and any token mounted into the pod. Rotate from a clean host, and review outbound connections from the serving node for the window the endpoint was reachable, since the attack requires LMDeploy to dial out to an attacker-controlled ZeroMQ address and that connection is the thing your egress logs would have recorded. Capture the process list, the open sockets and the egress logs before you restart anything.
3. Then upgrade to 0.16.0 or later, or rebuild. 0.17.0 is the current release on PyPI as of September 25, 2026. Affected versions are 0.9.2 through the 0.15.x line, so anything on 0.15 or below needs to move. If the previous step found the endpoint exposed, rebuild the host rather than upgrading in place.
4. Turn on the API key if you had not. LMDeploy does not authenticate this endpoint by default. An API key is not a substitute for network isolation, but on an instance you cannot patch yet it is the difference between "anyone who can route to the port" and "anyone who also has the key."

3. Amazon Q Developer language server: opening and trusting a crafted workspace runs its commands (CVE-2026-12957)

GHSA-xhcr-j4j9-3gh7 entered the advisory database on September 24, 2026, alongside a companion file-write issue (GHSA-6v3r-4p5c-mrp5). The language server behind Amazon Q Developer enforced its trust boundary improperly: when a user opens a maliciously crafted workspace and approves it, commands defined in that workspace's project-level configuration files may be executed automatically. The advisory rates it CVSS v4 8.5 and names the affected integrations as Amazon Q Developer for Visual Studio Code, JetBrains IDEs, Eclipse, and Visual Studio. AWS Security credits Wiz and Maor Dokhanian with the disclosure.

The reason this ranks above several higher-scored server-side bugs in this edition is the population and the triggering action. Cloning a repository and opening it in your editor is something this audience does many times a week, frequently with code from people they do not know, and the machine it happens on is usually the one holding SSH keys, cloud credentials, and an authenticated session to production. The approval prompt is real mitigation, but it is the kind of prompt people click through when they have just deliberately opened a project.

Am I affected?

# npm-resolved copies anywhere in your projects
python3 - <<'PY'
import json, glob
WATCH = {"cline":"3.0.30", "@bytebase/dbhub":"0.22.6",
         "@rsdoctor/rspack-plugin":"1.5.16", "@aws/lsp-codewhisperer":"0.0.117"}
def walk(f, node, prefix="dependencies"):
    # lockfileVersion 2/3 use a flat "packages" map; v1 uses nested "dependencies"
    for name, meta in (node or {}).items():
        if name in WATCH:
            print(f"{f}: {name} {meta.get('version')} (fixed in {WATCH[name]})")
        walk(f, meta.get(prefix), prefix)

for f in glob.glob("**/package-lock.json", recursive=True):
    try: d = json.load(open(f))
    except Exception: continue
    for path, meta in d.get("packages", {}).items():          # v2 / v3
        name = path.split("node_modules/")[-1]
        if name in WATCH:
            print(f"{f}: {name} {meta.get('version')} (fixed in {WATCH[name]})")
    walk(f, d.get("dependencies"))                            # v1
# yarn.lock and pnpm-lock.yaml are not covered; for those use:
#   npm ls --all cline @bytebase/dbhub @rsdoctor/rspack-plugin @aws/lsp-codewhisperer
PY

# quick grep equivalent if you just want to know whether it is present
grep -rn --include='package-lock.json' -E '"node_modules/(@aws/lsp-codewhisperer|@bytebase/dbhub|@rsdoctor/rspack-plugin|cline)"' .

# Installed extension versions (VS Code). Publisher ids do not contain the
# product name you expect: Amazon Q is amazonwebservices.amazon-q-vscode and
# Cline has shipped as saoudrizwan.claude-dev, so grep widely and read the
# full list if this comes back empty rather than assuming you are clean.
code --list-extensions --show-versions 2>/dev/null \
  | grep -iE 'amazon|aws|codewhisperer|cline|claude-dev'
code --list-extensions 2>/dev/null | wc -l   # sanity: did the command work at all?

For the IDE extensions the version that matters is Language Servers for AWS 1.69.0 or later, and the npm floor is @aws/lsp-codewhisperer 0.0.117. Two advisories are in play: the main issue here (CVE-2026-12957) is fixed in 1.65.0 / 0.0.113, but its companion CVE-2026-12958 is not fixed until 1.69.0 / 0.0.117, so 1.65.0 is not far enough. The registry shows 0.0.128 as current as of September 25, 2026, which clears both. The extension bundles its own copy of the language server, so updating the extension through your IDE's marketplace is the action; the npm check above is for projects that vendor it directly. This bulletin did not establish which extension release bundles 1.69.0, so "update to the latest extension" is the only check it can offer for the IDE case.

Response

1. Update the Amazon Q extension in every IDE you use. Visual Studio Code, JetBrains, Eclipse, and Visual Studio are all named. Do this on personal machines that touch work repositories too, which is the population that most often runs months behind.
2. Change how you open unfamiliar repositories. Until every workstation is updated, open code you did not write in a container, a devcontainer, or a VM rather than your primary profile, and decline the workspace trust prompt on first open. This is the control that survives the next bug of this shape, which is why it is worth the friction.
3. Go past 1.65.0: the companion advisory needs a later release. GHSA-6v3r-4p5c-mrp5 is CVE-2026-12958 (CVSS 8.5), an arbitrary file write through missing symlink validation in the same component, fixed in Language Servers for AWS 1.69.0 / npm 0.0.117, not in 1.65.0 / 0.0.113. Upgrading only to 1.65.0 leaves the file write open, so 1.69.0 is the floor for both issues.

4. Cline: any website you visit can drive the local dashboard into code execution (CVE-2026-59723)

GHSA-3cj3-hqcr-g934 entered the database on September 24, 2026, for an origin-validation failure (CWE-346) rated CVSS 8.8. The Cline Hub dashboard listens on 127.0.0.1:8787 by default and accepts WebSocket connections at /browser. When the ROOM_SECRET environment variable is unset, which is the default for local binds, the authorization function returns true unconditionally and never inspects the HTTP Origin header. Binding to loopback is not a defense here: the browser will happily open a cross-origin WebSocket to localhost on behalf of any page the developer is viewing.

From there the advisory describes read and write. Reads give session metadata and workspace state. Writes add arbitrary MCP server entries, including stdio entries whose command is a shell command, to the victim's settings file, and dashboard sessions default to autoApprove: true, so the injected server runs with the developer's privileges. The advisory includes a working Docker-based proof of concept demonstrating exactly that injection. This is the same architectural failure as item 5's dbhub DNS rebinding and item 8's Rsdoctor server: a local service treating "bound to localhost" as though it were an authentication boundary.

Am I affected?

# is the dashboard running, and is ROOM_SECRET set for it?
ss -lntp 2>/dev/null | grep -E '(0\.0\.0\.0|\*|\[::\]|127\.0\.0\.1):8787\b' \
  || lsof -nP -iTCP:8787 -sTCP:LISTEN 2>/dev/null
pgrep -af 'cline' 2>/dev/null
# Take the pid from the socket, not from pgrep: a name match also hits VS Code
# extension hosts, unrelated helpers, and the shell running this very snippet.
pid=$(sudo ss -lntpH 'sport = :8787' 2>/dev/null | grep -oE 'pid=[0-9]+' | head -1 | cut -d= -f2)
if [ -n "$pid" ]; then
  tr '\0' '\n' < "/proc/$pid/environ" | grep '^ROOM_SECRET=' || echo "ROOM_SECRET not set (pid $pid)"
else
  echo "nothing listening on 8787"
fi

# installed CLI version
cline --version 2>/dev/null ; npm ls -g cline --depth=0 2>/dev/null

# has anything been written into your MCP settings that you did not add?
# Cline's settings path has moved between releases, so match on content rather than one filename:
grep -rl --include='*.json' '"mcpServers"' "$HOME" 2>/dev/null | while read -r f; do
  echo "== $f"
  python3 -c "
import json, sys
d = json.load(open(sys.argv[1]))
for k, v in d.get('mcpServers', {}).items():
    print('   ', k, v.get('command'), v.get('args'))
" "$f"
done

The environment check reads ROOM_SECRET from the running process rather than from your shell profile, which is the distinction that matters if the dashboard was launched from a different session. It derives the pid from whatever holds port 8787 because a name match on "cline" also catches VS Code extension hosts and the shell running the snippet, and picking the wrong process reports a host that is actually mitigated as vulnerable. ROOM_SECRET not set against a dashboard below 3.0.30 is the vulnerable configuration; nothing listening means the dashboard is not running right now, which is not the same as never having run. The settings-file listing prints each configured MCP server with its command and arguments; review it against what you actually added, since an injected stdio entry is the documented post-exploitation artifact and is the one thing here that persists after you close the browser.

Response

1. Upgrade to 3.0.30 or later. 3.0.65 is the current release on npm as of September 25, 2026 (published September 24). Anything below 3.0.30 is affected.
2. Set ROOM_SECRET if you cannot upgrade now. A set secret is what makes the authorization function do its job, so it is a genuine stopgap rather than a cosmetic one, but it depends on your launching the dashboard with it set every time.
3. Audit your MCP settings first, and treat a hit as a compromised workstation, not a config cleanup. Exploitation requires only that you ran the dashboard and visited a page, neither of which you would remember as an event, so do this before concluding the upgrade was preventive. Review every configured MCP server against what you intentionally installed. If you find an entry you cannot account for, code has already run as you: an injected stdio entry runs a shell command with your privileges under autoApprove: true. Disconnect the machine from the network, copy the settings file and whatever its command points at before deleting anything, rotate every credential that workstation holds from a different machine, and rebuild rather than removing the entry and carrying on.

5. Two MCP servers with broken authentication: mcp-atlassian (CVE-2026-77244) and dbhub (CVE-2026-61742)

Both entered the advisory database in this window, and together they make a point worth more than either one alone. MCP servers are being written at speed, they are given broad credentials on purpose, and their HTTP transports are repeatedly shipping with authentication that does not authenticate.

mcp-atlassian (GHSA-wrhw-j3f9-8vc6, database entry September 22) is rated CVSS 10.0. Its AtlassianOpaqueTokenVerifier accepted any non-empty string as a valid bearer token, and with OAuth disabled, which is the default, the server then falls back to the Jira and Confluence credentials stored in its environment. Anyone who could reach the HTTP transport could therefore read and write every Jira issue, comment, and attachment and every Confluence page the configured account could reach, create persistent webhooks and automation rules, and do all of it under the operator's identity, which is also what makes it hard to see afterwards in an audit log. Affected is everything below 0.22.0; 0.22.0 shipped July 10 and 0.23.1 is current on PyPI as of September 25, 2026.

@bytebase/dbhub (GHSA-fm8p-53ww-hf6w, database entry September 24) is rated CVSS 9.3. Its HTTP transport tried to validate origin by comparing the Origin hostname against the Host header, which is an equality check rather than membership in an allowlist. An attacker-controlled domain that rebinds to the victim's dbhub instance satisfies both headers at once, so the server accepts the request and reflects the origin back. The result is unauthenticated MCP tool execution from a web page the victim visits: arbitrary SQL, schema enumeration, writes where the tools allow them, and exfiltration through the browser. Affected is 0.22.4 and below, fixed in 0.22.5; the registry shows 1.3.1 as current, published September 21, 2026. A companion advisory, GHSA-mwwr-p57h-56pf (CVE-2026-61788, CVSS 7.4), covers read-only mode failing to prevent database writes: the connection-level enforcement was never wired into the configuration system, and the statement classifier only reads leading keywords, so writes slip through function calls such as setval(), lo_export() and dblink_exec(). It is fixed in 0.22.6, so 0.22.5 is not far enough.

Am I affected?

# mcp-atlassian: installed version, and whether the HTTP transport is exposed
python3 -c "
from importlib.metadata import version, PackageNotFoundError
try: print('mcp-atlassian', version('mcp-atlassian'))
except PackageNotFoundError: print('mcp-atlassian not installed')
"

# the authentication bug is only reachable over the HTTP/SSE transport, not stdio
pgrep -af 'mcp-atlassian|dbhub' 2>/dev/null
# ss prints the executable name (python3, node, uv), never the package, so do NOT
# grep for the package name. Match on the pids pgrep just found, and note that the
# process column needs root:
pids=$(pgrep -d'|' -f 'mcp-atlassian|dbhub')
[ -n "$pids" ] && sudo ss -lntpH | grep -E "pid=($pids)"
# ... or just list every non-loopback listener and recognise your own:
sudo ss -lntpH | grep -vE '127\.0\.0\.1:|\[::1\]:'

# Does a nonsense bearer token get accepted? Use YOUR port from the step above.
# Compare two requests: a bad token, and no Authorization header at all.
curl -s -o /dev/null -w 'bad-token: %{http_code}\n' -H 'Authorization: Bearer not-a-real-token' \
  -H 'Accept: application/json, text/event-stream' http://127.0.0.1:PORT/mcp
curl -s -o /dev/null -w 'no-header: %{http_code}\n' \
  -H 'Accept: application/json, text/event-stream' http://127.0.0.1:PORT/mcp

# dbhub via the lockfile scan from section 3, or globally
npm ls -g @bytebase/dbhub --depth=0 2>/dev/null

Use the port you actually bound the server to; this bulletin does not know it and any number printed here would be a guess. Read the bearer probe by what it rules out, not by looking for a 200: anything other than 401 or 403 on the bad-token request means the verifier accepted the token. A streamable-HTTP MCP endpoint that passes authentication and then rejects the request on content negotiation or method commonly answers 400, 405 or 406, so waiting for a 200 will make a vulnerable server look fine. The second request is the control: if the bad token and no token at all produce the same status, the token is not being checked. A 401 from a reverse proxy in front of the server also looks like a pass, so run this against the server's own port. Run it against your own instance only. If you run either server over stdio rather than an HTTP transport, the authentication bypass is not reachable, though you should still upgrade.

Response

1. Upgrade both: mcp-atlassian to 0.22.0 or later, dbhub to 0.22.6 or later. 0.22.6 rather than 0.22.5, because the read-only companion (CVE-2026-61788) is fixed there. Current releases are 0.23.1 and 1.3.1 respectively as of September 25, 2026, and either upgrade clears both floors.
2. Assume the blast radius is the credential, not the server. An MCP server's damage is bounded by the token you gave it, and these were given Atlassian and database credentials. If either server was reachable over HTTP by anything you do not control, rotate the Atlassian API token or database account it used, then review Jira and Confluence audit logs and database logs for activity attributed to that identity.
3. Stop putting MCP servers on network transports by default. Use stdio where the client supports it. Where you need HTTP, bind to loopback and require authentication at a proxy in front, and do not treat an origin check as one. Items 4, 5, and 8 in this bulletin are the same mistake in three different projects, which is the argument for fixing it at the deployment pattern rather than per package.
4. Scope the credentials down. A read-only Jira account and a database role with no write grants would have turned both of these from a compromise into an information disclosure. dbhub's read-only mode specifically did not hold before 0.22.6 (GHSA-mwwr-p57h-56pf), and it failed in two independent ways at once, which is the argument for enforcing read-only at the database's own grant table rather than in the tool that connects to it.

6. Podman: a malicious image can pull host environment variables into the container (CVE-2026-57231)

GHSA-4hq8-gpf5-8p68 entered the database on September 24, 2026, rated CVSS 7.5. Podman reused its command-line environment-variable parsing for the environment section of an image's configuration, and that parser treats a bare key with no value as "inherit this one from the current environment." An image that declares an environment entry with just a key therefore tricks Podman into passing that variable from the host session into the container. Wildcards make it considerably worse, because a wildcard entry can pull every variable in the Podman session's environment. The fix requires image environment entries to follow key=value strictly and rejects malformed ones.

Who this matters to: anyone who runs images they did not build, which in practice means CI runners pulling third-party base images and developers trying things from a registry. The value at risk is whatever is in the environment of the shell or the CI job that invoked Podman, and on a CI runner that is frequently the entire secret set for the job.

Am I affected?

podman --version

# Go module consumers (if you embed Podman rather than run the binary).
# The v6 line moved to go.podman.io, so match both paths. Do not discard stderr:
# a failed resolution prints nothing and would read as "not present".
go list -m all | grep -E 'containers/podman|go\.podman\.io/podman|rabbitmq/amqp091-go'
grep -rnE 'containers/podman|go\.podman\.io/podman' go.mod go.sum

# inspect an image's declared environment before you run it:
# a bare key with no "=" is the malicious shape
podman image inspect --format '{{range .Config.Env}}{{println .}}{{end}}' IMAGE \
  | grep -vE '^[^=]+=' | grep -v '^$'

The final grep keeps only entries with no = at all, then drops the blank line the template leaves behind, so anything it prints is a bare key or a wildcard. Those are exactly the entries that cause host inheritance on an unpatched Podman; a patched one rejects them. Matching on ^[A-Za-z_][A-Za-z0-9_]*= instead would also flag legal keys containing dots or hyphens, which is noise, not a finding. Affected ranges are 1.8.1 and above but below 5.8.4 on the main module, with the older major lines affected at 2.2.1 and below, 3.4.7 and below, and 4.9.5 and below, and the v6 line, which lives at go.podman.io/podman/v6 rather than under github.com/containers, below 6.0.0.

Response

1. Upgrade to 5.8.4 or later, or 6.0.0 or later. v5.8.4 was tagged June 25, 2026, and the v5 line has since moved to 5.8.7 (September 16, 2026) per the Go module proxy. Your distribution's package is the practical path for most installs.
2. Reduce what is in the environment when you call Podman. This bug converts "the host session has secrets in its environment" into "the container has them." On CI runners, pass job secrets to the container explicitly with --env from a file rather than exporting them into the runner shell, which limits what any future variant of this bug can reach.
3. If you ran untrusted images on an unpatched Podman, rotate what was in that environment. There is no host-side artifact to hunt for: the leak is a variable arriving inside a container, which looks like normal operation. Treat the secrets that were in scope for those sessions as exposed if the image came from somewhere you do not control.

7. RabbitMQ amqp091-go: parser desynchronization and frame injection (CVE-2026-77411)

GHSA-c5pq-fr2g-9jpf entered the database on September 17, 2026, rated CVSS v4 9.5. The official Go AMQP client mishandled oversized string lengths on the wire: the guard if length > (^uint32(0) >> 1) { return } aborts parsing without consuming the bytes it was about to read. The parser's position in the stream is then wrong, and everything after it is read at the wrong offset, so attacker-controlled bytes get interpreted as legitimate AMQP frames. The advisory describes the consequences as payload injection, connection hijacking, and data manipulation.

Two companion advisories for the same module landed the same day: GHSA-j497-x9hr-x34x (silent data truncation and state corruption via a shortstr integer overflow) and GHSA-33mj-cw25-m34h (no explicit TLS minimum version in the URI parser). This bulletin did not open either advisory, so it does not know their fixed versions. Do not assume 1.13.0 clears them: the Amazon Q companion in section 3 needed a release four npm versions later than its main issue. Upgrade to the current 1.15.0 and read both advisories (linked in the sources) before treating either as closed.

Am I affected?

go list -m all 2>/dev/null | grep 'rabbitmq/amqp091-go'
grep -rn 'rabbitmq/amqp091-go' go.mod go.sum 2>/dev/null

# if you have it, govulncheck tells you whether the vulnerable path is reachable
govulncheck ./... | grep -E 'amqp091|CVE-2026-77411'

Anything below 1.13.0 is affected. govulncheck is worth the extra step here because it reports call-path reachability rather than mere presence in the module graph, which matters if amqp091-go arrived as a transitive dependency of something you do not actually use for AMQP.

Response

1. Upgrade to 1.13.0 or later. 1.13.0 was tagged July 21, 2026 and 1.15.0 (September 15, 2026) is current per the Go module proxy. go get github.com/rabbitmq/amqp091-go@v1.15.0 then rebuild and redeploy.
2. Check where the broker connection comes from. The attack needs a hostile peer on the AMQP connection. If your broker is on a private network and your services only talk to it, your exposure is limited to a compromised broker or someone already on that network. If any service connects to a broker operated by someone else, or accepts a broker URL from configuration a tenant controls, move this up your list.
3. Set a TLS minimum version explicitly. GHSA-33mj-cw25-m34h is about the URI parser not doing this for you. Pass your own tls.Config with MinVersion: tls.VersionTLS12 or higher rather than relying on the defaults the URI form gives you.

8. Rsdoctor: an unauthenticated API on all interfaces that returns your source (CVE-2026-61782)

GHSA-jmg2-rcxh-w8q3 entered the database on September 24, 2026, rated CVSS 7.5. The Rsdoctor build analyzer's report server combines four defects that compound: it calls server.listen(port, callback) with no host argument, which Node defaults to 0.0.0.0, so it listens on every interface; it sets Access-Control-Allow-Origin: * unconditionally, its POST /api/data/key endpoint has no authentication middleware, and the attacker-supplied key indexes the SDK data store directly with no allowlist. The advisory's summary is that any network-adjacent or remote attacker can send a single unauthenticated request and retrieve the full source. What comes back is the compiled modules' JavaScript source, the build configuration including absolute paths, error details and stack traces, and environment information.

The setting that determines your real exposure is where your builds run. On a laptop behind NAT this is mostly a local-network issue. On a shared CI runner, a build agent on a flat corporate network, or any cloud instance with a permissive security group, an analyzer server on 0.0.0.0 is reachable by everything that can route to the host, for as long as the build takes.

Am I affected?

# resolved version, with the fix floor, via the section 3 scan
grep -rn -A2 --include='package-lock.json' -E '"node_modules/@rsdoctor/' .
grep -rn --include='package.json' -E '"@rsdoctor/' .

# The analyzer port is RANDOM per build (roughly 3000-8999), so do not grep for a
# port. While a build is running, list every listener that is NOT loopback-only:
ss -lntpH 2>/dev/null | grep -vE '127\.0\.0\.1:|\[::1\]:'
#   ... 0.0.0.0:PORT, *:PORT and [::]:PORT all mean "every interface".

# Rsdoctor prints its own analyzer URL in the build log; probe THAT port:
#   grep -oE 'http://[^ ]+' build.log
curl -s -o /dev/null -w '%{http_code}\n' -X POST http://127.0.0.1:PORT/api/data/key
#   connection refused or 404 = nothing answering; any other HTTP status = the
#   endpoint answered an unauthenticated POST, which is the finding.

Affected is 1.5.15 and below, fixed in 1.5.16; the registry shows 1.6.4 (September 11, 2026) as current. Two traps here. The port is chosen at random per build rather than fixed, so any check written against a specific port number will miss an exposed server; the finding is an analyzer bound to anything other than loopback, whatever port it landed on. And reading defaultHost = '127.0.0.1' out of your installed @rsdoctor packages does not mean you are safe on 1.5.15 or below: per the advisory the bug is that the host was never passed to listen(), so that constant can sit in the package while the socket still binds everywhere. The advisory states 1.5.16 is what changes the effective default bind to 127.0.0.1.

Response

1. Upgrade to 1.5.16 or later. 1.6.4 is current on npm as of September 25, 2026.
2. Set disableClientServer: true in CI. The report server exists for interactive analysis on a developer's machine. There is no reason for it to run in an automated build, and disabling it removes the exposure on exactly the hosts where it is most reachable. Keep it enabled locally if you use it.
3. Treat a build config as disclosed if it ran exposed. The endpoint returns absolute paths and environment information alongside source. If your CI builds ran on a shared network with a vulnerable version, rotate anything that appears in build-time environment variables and assume internal path structure is known.

9. Roll-up: everything else that reached the advisory database this window

These are the remaining items from September 13 to 25 that touch this audience but do not warrant their own section, either because the affected population is narrower or because the fix is unremarkable. Two are given with full detail because they involve credentials or reach a wide dependency tree; the rest are listed at the level this bulletin verified them, which is the advisory listing plus the linked advisory page, and you should read the advisory for exact ranges before acting.

Am I affected?

# Go: the roll-up modules (sections 6 and 7 have their own checks above)
go list -m all | grep -E 'openbao/openbao|zitadel/zitadel|cilium/cilium|kcp-dev/kcp'
grep -rnE 'openbao/openbao|zitadel/zitadel|cilium/cilium|kcp-dev/kcp' go.mod go.sum

# OpenBao: recovery mode is the affected path, and it should never be routinely enabled
bao status 2>/dev/null | grep -iE 'recovery|version'
pgrep -af 'bao server.*-recovery' 2>/dev/null

# Python: hpack arrives under h2; check the resolved version, not the declaration
python3 -c "
from importlib.metadata import version, PackageNotFoundError
for p in ('hpack','h2','httpx'):
    try: print(p, version(p))
    except PackageNotFoundError: print(p, 'not installed')
"

For hpack the practical note is that a fix requires re-resolving the lockfile, because h2 pins a range rather than an exact version and a stale lockfile will keep 4.1.0 indefinitely. For OpenBao, the timing attack only applies while the server is running in recovery mode, which is a deliberate and short-lived administrative state for most operators; if you never run recovery mode, upgrade on your normal cadence.

Response

1. Fold these into your next dependency-update pass rather than treating them as incidents. None carries confirmed exploitation, and most have a narrow affected population. The exception is any product in the list you expose to the internet, which should move to the front.
2. Upgrade OpenBao to v2.6.0 and ZITADEL to 4.16.1 or 3.4.13 if you self-host either. Both hold authentication material for everything downstream of them, which is the reason to act ahead of cadence even without an exploitation signal. For ZITADEL specifically, restrict who can create or attach Actions and audit existing ones for filesystem require() calls in the meantime.
3. Re-resolve Python lockfiles once, covering anyio and hpack together. Both are transitive, both reached the database in this window, and one re-resolution with explicit floors of anyio>=4.14.2 and hpack>=4.2.0 settles both.

What this window actually shows

Strip out the scope limitation for a moment and one pattern runs through most of this edition. Items 4, 5, and 8 are the same architectural mistake in three unrelated projects: Cline, dbhub, and Rsdoctor each treated a local or loopback bind as though it were an authentication boundary, and each was wrong for a different reason. A browser will open a cross-origin WebSocket to localhost for any page you visit. DNS rebinding defeats an origin check written as an equality comparison. Binding to 0.0.0.0 was never loopback in the first place. The developer tooling around AI coding agents and build analysis is accumulating these faster than the server-side ecosystem ever did, because the threat model that says "it is only on my machine" feels true and is not.

The second pattern is the one the lead item is really about. anyio was fixed on July 12 and most teams' scanners did not mention it until September 18. hpack was fixed on June 23 and surfaced September 24. Podman's fix was tagged June 25 and surfaced September 24. If your vulnerability management is driven entirely by what Dependabot opens a pull request for, your exposure window is not the time between disclosure and your patch, it is the time between the fix and the database entry, plus your patch time, and the first of those is outside your control and was routinely two to three months in this window. Watching the release notes of the handful of dependencies that actually sit underneath your stack is the cheap correction.