IT-News

Cisco APIC: Mehrere Schwachstellen, was KMU jetzt tun sollten

Von Christopher Schütz · 2026-10-09 · 11 Min. Lesezeit
Der BSI CERT-Bund hat eine neue Warnung mit der Einstufung „hoch" veröffentlicht: Im Cisco Application Policy Infrastructure Controller stecken mehrere Schwachstellen, die ein Angreifer ausnutzen kann. Das Spektrum reicht von zusätzlichen Berechtigungen über das Ausführen fremden Codes bis zum Lahmlegen des Systems. Wer so einen Controller betreibt, sollte heute nicht auf den nächsten Wartungstermin warten. Wer keinen betreibt, kann an diesem Fall trotzdem lernen, wie man mit solchen Meldungen umgeht.

Was genau gemeldet wurde

Beginnen wir mit dem, was bekannt ist, und lassen weg, was wir nicht wissen. Die Meldung des BSI CERT-Bund trägt die Kennung WID-SEC-2026-3818 und ist mit „neu" und „hoch" gekennzeichnet. Sie betrifft den Cisco Application Policy Infrastructure Controller, kurz APIC. Es geht ausdrücklich um mehrere Schwachstellen, nicht um einen einzelnen Fehler.

Nach der Zusammenfassung des CERT-Bund kann ein Angreifer diese Schwachstellen ausnutzen, um sich erweiterte Berechtigungen zu verschaffen, beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen, Daten zu manipulieren oder offenzulegen oder einen Denial-of-Service-Zustand auszulösen. Diese Liste klingt nach Standardformulierung, wie sie in vielen Sicherheitsmeldungen steht. Sie lohnt trotzdem einen zweiten Blick, denn hier sind praktisch alle klassischen Schutzziele gleichzeitig berührt: Vertraulichkeit (Daten offenlegen), Integrität (Daten manipulieren) und Verfügbarkeit (Dienst lahmlegen). Dazu kommen die beiden Folgen, die in der Praxis am schwersten wiegen: Rechteausweitung und Codeausführung.

Was in der Kurzfassung nicht steht, sollten wir nicht erfinden. Welche Versionen betroffen sind, wie leicht sich die Lücken ausnutzen lassen, ob ein Angreifer vorher angemeldet sein muss und ob bereits Angriffe beobachtet wurden, entnehmen Sie bitte den Herstellerhinweisen und der Originalmeldung. Das ist kein Ausweichen. Wer in einer solchen Lage Details vermutet, die nicht belegt sind, trifft schlechte Entscheidungen. Die verlässliche Information ist: Es gibt eine Warnung mit hoher Kritikalität, und sie betrifft eine Komponente, die im Netzwerk eine zentrale Rolle spielt.

Warum ein Netzwerk-Controller kein gewöhnliches Gerät ist

Ein Controller wie der APIC ist keine Randfigur im Netz. Im Kern ist er die Stelle, an der Regeln für die Netzwerkinfrastruktur zentral festgelegt und an die angeschlossenen Komponenten verteilt werden. Statt jeden Switch einzeln zu konfigurieren, definiert man Vorgaben an einem Ort, und der Controller sorgt dafür, dass sie überall ankommen. Das spart Arbeit und macht große Umgebungen beherrschbar. Es bedeutet aber auch: Wer den Controller kontrolliert, hat im Zweifel Einfluss auf das ganze Netz.

Stellen Sie sich einen Schlüsselkasten vor, in dem die Zweitschlüssel für alle Türen hängen. Die einzelne Tür kann noch so gut gesichert sein. Wenn jemand den Kasten öffnet, nützt das wenig. Genauso ist es mit zentralen Steuerungssystemen. Ein Angreifer, der dort Code ausführen oder sich höhere Rechte verschaffen kann, muss nicht mehr jedes Gerät einzeln angreifen. Er kann Regeln ändern, Zugriffe freischalten oder Überwachung aushebeln, und zwar so, dass es wie normaler Betrieb aussieht.

Dazu kommt ein zweiter Punkt, der gern unterschätzt wird: Solche Systeme laufen häufig jahrelang unauffällig durch. Niemand schaut täglich auf den Controller. Es gibt keinen Nutzer, der sich beschwert, wenn etwas komisch aussieht, denn Anwender kommen mit dem System nie direkt in Berührung. Entsprechend selten werden sie aktualisiert, und entsprechend spät fällt auf, wenn sich jemand darin bewegt. Für Angreifer ist das ein attraktives Ziel: hohe Wirkung, geringe Entdeckungswahrscheinlichkeit.

Die Folgen im Klartext übersetzt

Die Aufzählung des CERT-Bund ist für Techniker geschrieben. Hier die Übersetzung für alle, die im Unternehmen Entscheidungen treffen.

Erweiterte Berechtigungen. Jemand mit eingeschränktem Zugang, etwa ein Konto mit wenigen Rechten oder ein kompromittierter Dienstleisterzugang, kann sich mehr Befugnisse verschaffen, als vorgesehen sind. In der Praxis ist das der Schritt, der aus einem kleinen Vorfall einen großen macht. Viele Einbrüche beginnen unspektakulär an einer Stelle mit wenig Rechten und wachsen dann durch genau solche Rechteausweitungen.

Beliebiger Code. Wer fremden Code auf einem System ausführen kann, hat es faktisch übernommen. Er kann Programme nachladen, Hintertüren einbauen oder das System als Sprungbrett in andere Bereiche nutzen. Die Kontrolle verschiebt sich vom Betreiber zum Angreifer.

Sicherheitsmaßnahmen umgehen. Das ist der Punkt, der in Besprechungen oft untergeht. Wenn Schutzmechanismen ausgehebelt werden können, helfen die schönsten Richtlinien nichts, weil sie nur auf dem Papier gelten. Ein Unternehmen glaubt dann, es sei abgeschottet, und ist es nicht.

Daten manipulieren oder offenlegen. Offenlegung bedeutet, dass Konfigurationen, Netzstrukturen oder Zugangsinformationen in falsche Hände geraten. Das ist doppelt unangenehm, weil solche Informationen den nächsten Angriff erleichtern. Manipulation ist noch heikler: Wenn jemand Regeln verändert, ohne dass es auffällt, kann er sich dauerhaft einrichten.

Denial-of-Service. Der Dienst fällt aus oder wird so beeinträchtigt, dass er nicht mehr zuverlässig arbeitet. Bei einem zentralen Netzwerkbaustein heißt das im schlimmsten Fall: Das Netz lässt sich nicht mehr steuern oder ändern, und Anwendungen, die davon abhängen, leiden mit. Für ein Unternehmen mit Onlineshop, Warenwirtschaft oder Produktionsanbindung ist das keine technische Randnotiz, sondern Umsatzausfall.

Warum das gerade den Mittelstand betrifft

Man könnte denken, solche Controller gehörten in Konzernrechenzentren und gingen den typischen Mittelständler nichts an. Das stimmt nur teilweise. Nach unserer Erfahrung finden sich Netzwerk-Controller dieser Art auch in mittelständischen Rechenzentren und Serverräumen: bei Unternehmen mit eigener Infrastruktur, bei Firmen, die Hosting für Kunden betreiben, bei Betrieben mit mehreren Standorten oder bei Dienstleistern, die für ihre Kunden die Netze betreuen. Selbst wenn Ihr Unternehmen keinen APIC im Haus hat, kann einer bei Ihrem IT-Dienstleister oder Rechenzentrumspartner stehen, über den Ihre Systeme laufen.

Genau hier liegt das eigentliche Problem im Mittelstand: nicht die Technik, sondern die Zuständigkeit. In kleineren IT-Abteilungen ist die Netzwerkinfrastruktur oft das Spezialgebiet einer einzigen Person. Wenn diese Person im Urlaub ist, krank wird oder das Unternehmen verlässt, weiß niemand mehr genau, welche Geräte wo stehen und wann sie zuletzt aktualisiert wurden. Und wenn die Wartung an einen externen Dienstleister ausgelagert ist, besteht die Gefahr, dass jeder glaubt, der andere kümmere sich.

Eine BSI-Warnung mit der Stufe „hoch" trifft dann auf eine Organisation, die gar nicht weiß, ob sie betroffen ist. Diese Unsicherheit ist selbst schon ein Risiko. Die erste Handlung nach so einer Meldung ist deshalb keine Reparatur, sondern eine Bestandsaufnahme: Haben wir das betroffene Produkt im Einsatz, direkt oder über Dritte?

Es gibt außerdem eine rechtliche und vertragliche Seite. Wer Kundendaten verarbeitet, trägt Verantwortung für deren Schutz, und die Geschäftsführung kann sich nicht mit dem Hinweis entlasten, man habe die Warnung nicht gesehen. Je nach Branche und Größe greifen zudem verschärfte Pflichten durch Regelungen wie NIS2. Wie diese Anforderungen im Mittelstand aussehen und was sie praktisch bedeuten, haben wir auf unserer Seite zu NIS2 & IT-Sicherheit zusammengefasst. Ein funktionierender Prozess für Sicherheitswarnungen gehört dort ausdrücklich zum Pflichtprogramm.

Patch-Management ist Chefsache

Das Wort „Patch-Management" klingt nach Arbeit für die Technik, und im Tagesgeschäft ist es das auch. Aber die Entscheidung, wie schnell und mit welcher Priorität Updates eingespielt werden, ist eine Führungsentscheidung. Sie legt fest, wie viel Ausfallrisiko durch eine Wartung gegen wie viel Angriffsrisiko durch eine offene Lücke abgewogen wird. Diese Abwägung kann die Technik nicht allein treffen, denn sie berührt Betriebszeiten, Budgets und Haftung.

In vielen Betrieben läuft es anders: Updates werden verschoben, weil „gerade nichts Zeit hat", weil niemand die Verantwortung für einen möglichen Neustart übernehmen will oder weil das letzte Update einmal Probleme gemacht hat. Jede dieser Begründungen ist menschlich nachvollziehbar. Zusammen ergeben sie aber einen Zustand, in dem bekannte Lücken Wochen oder Monate offen bleiben. Und bekannte Lücken sind für Angreifer die bequemste Eintrittskarte, weil sie nicht einmal etwas Neues entdecken müssen.

Was in der Praxis hilft:

  • Klare Verantwortung. Für jedes System im Unternehmen gibt es einen Namen, der für Updates zuständig ist, und eine Vertretung. Nicht „die IT", sondern eine Person.
  • Feste Fristen nach Kritikalität. Zum Beispiel: Warnungen der Stufe „hoch" werden innerhalb weniger Tage bewertet und umgesetzt, kritische noch schneller, niedrige im regulären Wartungsfenster. Die genauen Zahlen legen Sie selbst fest. Wichtig ist, dass es sie gibt und dass jemand ihre Einhaltung kontrolliert.
  • Wartungsfenster im Voraus. Wer erst bei einer Warnung überlegt, wann man das System überhaupt anfassen darf, verliert Zeit. Regelmäßig geplante Fenster nehmen den Druck.
  • Ein vollständiges Inventar. Sie können nur patchen, was Sie kennen. Eine einfache Liste mit Gerät, Standort, Version, Zuständigem und Ansprechpartner beim Hersteller oder Dienstleister reicht für den Anfang.
  • Testumgebung oder Rückfallplan. Wer ein Update nicht gefahrlos einspielen kann, schiebt es auf. Ein dokumentierter Weg zurück senkt die Hemmschwelle.

Wenn Sie dafür Unterstützung wollen, finden Sie bei uns den Bereich IT-Sicherheit, in dem wir solche Prozesse mit Mittelständlern aufsetzen, von der Bestandsaufnahme bis zur laufenden Überwachung.

Netzwerksegmentierung: Der Schaden bleibt klein

Patchen ist die eine Hälfte. Die andere Hälfte ist die Annahme, dass es trotzdem einmal schiefgeht. Kein Unternehmen aktualisiert in dem Moment, in dem eine Lücke bekannt wird, und manchmal gibt es für eine Schwachstelle zunächst gar keinen Fix. Für diese Zeit entscheidet die Architektur darüber, wie groß der Schaden werden kann.

Netzwerksegmentierung heißt, das Netz in getrennte Bereiche zu teilen, zwischen denen nur das erlaubt ist, was fachlich nötig ist. Ein flaches Netz, in dem jedes Gerät mit jedem sprechen darf, gleicht einem Haus ohne Innentüren: Wer einmal drin ist, kommt überall hin. Ein segmentiertes Netz hat Türen, und die wichtigsten sind abgeschlossen.

Für Steuerungssysteme wie einen Netzwerk-Controller bedeutet das konkret:

1. Verwaltungszugang abtrennen. Die Verwaltungsoberfläche gehört in ein eigenes Management-Netz, das nicht aus dem normalen Büronetz oder gar aus dem Internet erreichbar ist. Wer sie von überall aufrufen kann, hat die Angriffsfläche unnötig vergrößert.
2. Zugriff auf wenige Wege beschränken. Verwaltet wird nur von definierten Arbeitsplätzen oder über einen gesicherten Zugang mit Mehrfaktor-Anmeldung, nicht vom Laptop in der Kantine.
3. Administrative Konten sparsam vergeben. Je weniger Konten weitreichende Rechte haben, desto weniger Ausgangspunkte gibt es für Rechteausweitung.
4. Verkehr protokollieren. Auch ein gut abgeschottetes System sollte nachvollziehbar machen, wer wann zugegriffen hat. Auffälligkeiten sieht man nur, wenn jemand hinschaut.
5. Wichtiges von Unwichtigem trennen. Gäste-WLAN, Büro-PCs, Produktion, Server und Verwaltung sind unterschiedliche Vertrauenszonen und gehören nicht in dasselbe Segment.

Segmentierung ist kein Projekt für ein Wochenende, aber sie lässt sich schrittweise einführen. Beginnen Sie mit den Verwaltungszugängen, dann mit den wertvollsten Systemen. Jeder Schritt macht die Lage besser.

Die ersten 24 Stunden nach einer BSI-Warnung

Der Titel dieses Beitrags verspricht einen Handlungsplan für den ersten Tag. Hier ist er. Er funktioniert nicht nur für diese Meldung, sondern für jede Warnung mit hoher Kritikalität.

Stunde 0 bis 2: Betroffenheit klären. Jemand liest die Meldung im Original, nicht nur die Zusammenfassung, und prüft anhand Ihres Inventars, ob das genannte Produkt bei Ihnen oder bei einem Dienstleister im Einsatz ist. Falls Sie unsicher sind, fragen Sie Ihren IT-Betreuer schriftlich und konkret: „Setzen Sie den Cisco APIC für uns oder in unserer Umgebung ein, ja oder nein?" Eine klare Antwort ist wichtiger als eine freundliche.

Stunde 2 bis 6: Risiko bewerten. Wenn Sie betroffen sind: Ist die Verwaltungsoberfläche aus dem Internet oder aus dem Büronetz erreichbar? Wer hat Zugang? Gibt es vom Hersteller bereits Updates oder Hinweise zur Absicherung? Die Herstellerhinweise sind hier die verbindliche Quelle für betroffene Versionen und empfohlene Maßnahmen.

Stunde 6 bis 12: Sofortmaßnahmen. Solange das Update nicht eingespielt ist, verkleinern Sie die Angriffsfläche: Zugriff auf die Verwaltung auf das Nötigste beschränken, unnötige Freigaben schließen, Zugangsdaten und Konten prüfen. Gleichzeitig sichern Sie die aktuelle Konfiguration, damit Sie im Fall der Fälle zurückkehren können.

Stunde 12 bis 20: Update planen und einspielen. Vereinbaren Sie das Wartungsfenster, informieren Sie die betroffenen Fachbereiche und spielen Sie die Aktualisierung nach Herstellerangaben ein. Ist ein sofortiges Update nicht möglich, halten Sie schriftlich fest, warum nicht, welche Ersatzmaßnahmen gelten und bis wann nachgezogen wird.

Stunde 20 bis 24: Prüfen und dokumentieren. Läuft das System wie vorher? Gibt es in den Protokollen ungewöhnliche Zugriffe aus der Zeit vor dem Update? Halten Sie kurz fest, was passiert ist: Wer hat wann was entschieden? Diese Notiz kostet zehn Minuten und ist im Ernstfall Gold wert, sowohl für die Nachvollziehbarkeit als auch gegenüber Kunden oder Prüfern.

Dieser Ablauf klingt aufwendig, ist aber in kleinen Umgebungen oft in wenigen Stunden erledigt, wenn die Vorarbeit stimmt. Ohne Inventar, ohne Zuständigkeit und ohne Wartungsfenster wird dieselbe Aufgabe zur Woche. Der Unterschied liegt nicht in der Technik, sondern in der Vorbereitung.

Was das für den Mittelstand bedeutet

Aus der Meldung und unserer Erfahrung lassen sich konkrete Schritte ableiten, nach Dringlichkeit sortiert.

Diese Woche:

  • Klären Sie, ob in Ihrer eigenen Umgebung oder bei Ihrem Dienstleister Cisco-APIC-Systeme laufen. Fragen Sie schriftlich nach und lassen Sie sich die Antwort bestätigen.
  • Lesen Sie die Herstellerhinweise zu den betroffenen Versionen und gleichen Sie sie mit Ihrem Bestand ab.
  • Prüfen Sie, wer die Verwaltungsoberfläche erreichen kann, und schränken Sie das ein, wo es zu weit gefasst ist.
  • Sichern Sie die Konfiguration, bevor Sie etwas ändern.

In den nächsten Wochen:

  • Legen Sie ein Inventar aller Netzwerk- und Serverkomponenten an, mit Version, Zuständigem und Wartungsstand.
  • Definieren Sie Fristen für Sicherheitsupdates nach Kritikalität und lassen Sie sich die Einhaltung monatlich berichten.
  • Benennen Sie für jedes zentrale System einen Verantwortlichen und eine Vertretung.
  • Richten Sie ein abgesichertes Management-Netz ein, falls es noch keines gibt.

Dauerhaft:

  • Abonnieren Sie die Warnungen des BSI oder lassen Sie Ihren Dienstleister das verbindlich für Sie übernehmen, mit einer festen Meldung an die Geschäftsführung bei Stufe „hoch" und darüber.
  • Prüfen Sie einmal jährlich, ob Ihre Netzwerksegmentierung noch zur tatsächlichen Nutzung passt.
  • Üben Sie den Ernstfall: Was passiert, wenn der zentrale Controller morgen ausfällt? Wer ist erreichbar, wo liegen die Backups, wie lange dauert die Wiederherstellung?
  • Wenn Sie regional Unterstützung vor Ort suchen, hilft Ihnen unser IT-Service Friesland bei Bestandsaufnahme, Wartung und Notfallplanung.

Ein letzter Gedanke zur Haltung: Es geht nicht darum, bei jeder Meldung in Alarmstimmung zu verfallen. Die meisten Warnungen betreffen Produkte, die Sie nicht einsetzen, und dann reicht ein Haken auf der Liste. Es geht darum, dass der Haken bewusst gesetzt wird, von jemandem, der die Frage tatsächlich beantwortet hat. Dieses Muster macht den Unterschied zwischen einem Unternehmen, das gelassen bleibt, und einem, das im Ernstfall erst anfängt zu suchen.

Häufige Fragen

Betrifft die Meldung mein Unternehmen, auch wenn wir keinen Cisco APIC kennen?

Möglicherweise ja, auch ohne eigenes Gerät. Ihr Rechenzentrumspartner oder IT-Dienstleister kann das System einsetzen, und Ihre Anwendungen hängen dann indirekt daran. Fragen Sie schriftlich nach, ob und in welcher Form das Produkt in Ihrer Umgebung läuft. Eine klare Antwort schafft Sicherheit in beide Richtungen.

Was bedeutet die Einstufung „hoch" des BSI konkret?

Sie signalisiert, dass die Schwachstellen ernst zu nehmen sind und zeitnah bewertet werden sollten. Sie ist keine Aussage darüber, ob Ihr Unternehmen betroffen ist oder ob bereits Angriffe laufen. Behandeln Sie sie als Auslöser für Ihren Prüfprozess: Betroffenheit klären, Risiko bewerten, Maßnahmen planen.

Reicht es, auf das nächste reguläre Wartungsfenster zu warten?

Bei einer Meldung dieser Stufe an einem zentralen Netzwerksystem in der Regel nicht, wenn Sie betroffen sind. Prüfen Sie zumindest sofort, wie gut das System abgeschirmt ist, und ergreifen Sie Übergangsmaßnahmen wie eine eingeschränkte Erreichbarkeit der Verwaltung. Das Update selbst sollten Sie so früh einplanen, wie es der Betrieb erlaubt.

Was tun, wenn ein Update sich nicht sofort einspielen lässt?

Dann zählt die Schadensbegrenzung: Zugriff auf das System auf das Nötigste reduzieren, Konten und Zugangsdaten prüfen, Protokolle beobachten und die Entscheidung samt Frist dokumentieren. Planen Sie das Update verbindlich nach, statt es offen zu lassen.

Wie bereite ich mein Unternehmen auf künftige Warnungen vor?

Mit drei Dingen: einem aktuellen Inventar, klaren Zuständigkeiten und festen Fristen je nach Kritikalität. Ergänzen Sie das durch eine saubere Netzwerksegmentierung und ein getestetes Backup. Mit diesem Gerüst wird aus jeder Warnung eine Routineaufgabe statt einer Krisensitzung.

Brauche ich dafür einen externen Dienstleister?

Nicht zwingend, aber in kleinen Teams ist es oft sinnvoll, Überwachung und Wartung zu teilen oder abzugeben, weil Urlaub, Krankheit und Spezialwissen sonst zu Lücken führen. Entscheidend ist, dass die Verantwortung klar geregelt und schriftlich festgehalten ist, egal ob intern oder extern.

Quellen

Weiterführende Leistungen & Ratgeber

IT-Sicherheits-Fahrplan 2026 NIS2 & IT-Sicherheit Alle Ratgeber & News

Sie möchten wissen, ob eine dieser Lücken Ihre Systeme betrifft? Wir prüfen Ihre IT und richten ein passendes Schutzkonzept ein. Fordern Sie einen Sicherheits-Check an oder rufen Sie direkt an: +49 1556 7039821.