Argo CD, Android, NetBox, Ollama, Redis, RabbitMQ and Velociraptor - New BSI Patch Queue
Finding: Argo CD WID-SEC-2026-1383 puts GitOps exposure on the review list
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1383 as a high-severity information disclosure advisory for Argo CD. The available source set does not include a CVE, affected-version table, vendor advisory, exploitation report, indicators of compromise, or named victim.
That keeps confidence low, but it does not make the item irrelevant. Argo CD often sits close to deployment metadata, repository references and operational context. Security teams should identify externally reachable Argo CD instances, confirm ownership, and route the advisory to the platform team for version and patch review.
Finding: Android WID-SEC-2026-1360 needs fleet-owner mapping before severity escalation
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1360 for Google Android with administrator-level code execution wording. No CVE or vendor bulletin was present in the available source set, so this should not be treated as a fully corroborated Android emergency.
The practical step is fleet mapping. Mobile and endpoint teams should check whether supported enterprise builds, OEM update channels and managed-device baselines map to the BSI item. If vendor detail appears, this can move from watch item to scheduled update action.
Finding: IBM App Connect Enterprise Certified Container WID-SEC-2026-1407 reaches integration middleware
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1407 as multiple vulnerabilities in IBM App Connect Enterprise Certified Container. The source set does not provide affected images, fixed tags, exploit status or CVE identifiers.
Integration middleware can carry sensitive data paths between systems, so ownership matters even where evidence is thin. Teams running IBM App Connect in containers should identify image versions, deployment owners and update windows, then wait for vendor-specific detail before assigning emergency severity.
Finding: NetBox WID-SEC-2026-1355 flags code-execution risk in infrastructure source-of-truth tooling
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1355 for NetBox with code-execution wording. The available corpus does not corroborate the item with vendor detail, a CVE record or exploitation evidence.
NetBox commonly holds infrastructure inventory, IP address management and configuration context. That makes exposure review sensible. Confirm whether NetBox is internet-facing, whether authentication and plugin boundaries are controlled, and whether current versions align with any vendor follow-up.
Finding: Ollama WID-SEC-2026-1379 is an AI-platform exposure prompt
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1379 as an Ollama information disclosure advisory. No active exploitation, CVE or vendor advisory was present in the available source material.
The useful action is not panic, it is exposure hygiene. Ollama deployments should be checked for host binding, reverse-proxy configuration, authentication assumptions and reachable model endpoints. Teams experimenting with local AI services should make sure those services have not drifted into production-like exposure without the same controls.
Finding: Red Hat ACM/MCE WID-SEC-2026-1367 affects Kubernetes management review
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1367 for Red Hat Advanced Cluster Management and Multicluster Engine for Kubernetes, with remote execution and availability-risk wording. The source set does not include CVE identifiers, fixed package versions or exploit details.
Kubernetes management planes deserve careful routing. Identify whether Red Hat ACM or MCE is deployed, confirm cluster-management ownership, and prepare a patch window once vendor advisories provide affected-version detail.
Finding: Red Hat Enterprise Linux libsoup WID-SEC-2026-1409 is a dependency-tracking item
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1409 as an information disclosure item for Red Hat Enterprise Linux libsoup. The available source set does not include the dependency versions affected or a vendor fix reference.
This belongs in platform dependency tracking. Linux owners should map where libsoup is present through package inventory and follow Red Hat-specific update channels before assigning business impact.
Finding: Redis WID-SEC-2026-1370 warrants fast inventory, even at low confidence
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1370 as multiple code-execution vulnerabilities in Redis. The source set lacks CVE detail and exploitation evidence, so the confidence label stays low.
Redis is often deployed as a cache, queue, session store or internal data service. That ubiquity makes basic exposure checks worthwhile. Confirm version ownership, authentication, network binding and whether any Redis instance is reachable from untrusted networks.
Finding: RabbitMQ WID-SEC-2026-1397 adds broker patch management to the queue
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1397 as multiple vulnerabilities in RabbitMQ. No active exploitation, CVE list or vendor advisory appeared in the available source set.
Message brokers can sit on critical application paths. Owners should identify deployed RabbitMQ versions, check management interface exposure and prepare for patch scheduling if vendor confirmation follows.
Finding: Rapid7 Velociraptor WID-SEC-2026-1368 touches defensive tooling
Confidence: Unverified
BSI CERT-Bund lists WID-SEC-2026-1368 as multiple vulnerabilities in Rapid7 Velociraptor. The available source set does not show CVE identifiers, affected builds, exploitation or vendor confirmation.
Defensive tooling is still infrastructure. DFIR teams should confirm whether Velociraptor servers and clients are deployed, verify management-plane exposure, and watch for vendor detail before escalating.
Why This Matters
Today’s change is the breadth of the patch queue, not evidence of a live campaign. The affected product set crosses deployment automation, mobile devices, integration containers, infrastructure inventory, AI tooling, Kubernetes management, Linux dependencies, Redis, RabbitMQ and DFIR tooling.
That spread is operationally awkward. It requires coordination across several owners, and thin source detail makes prioritisation harder. The right response is disciplined inventory: find the assets, assign owners, collect vendor detail, then patch in the order that matches exposure and business importance.
- Recommended Actions
- Assign owners for Argo CD, Android fleet management, IBM App Connect containers, NetBox, Ollama, Red Hat ACM/MCE, RHEL libsoup, Redis, RabbitMQ and Velociraptor.
- Treat all ten WID entries as low-confidence or unverified until vendor advisories, CVEs or affected-version details appear.
- Prioritise exposure checks for internet-facing Argo CD, NetBox, Ollama, Redis, RabbitMQ and Velociraptor services.
- Confirm Redis and RabbitMQ are not reachable from untrusted networks and have authentication controls aligned with internal policy.
- Track vendor channels for affected versions, fixed releases and severity updates.
- Manual publication note: because cross-publication dedup verification could not be completed, compare this queue against recent public posts before release.
All findings grounded in a13e intelligence sweeps through 05:30 UTC 08 May 2026.