Oktsec Radar is a public tool for reviewing security advisories and recording a response. A team can find a product it uses, check the affected versions and evidence, then keep a record of what needs attention and who will handle it. Reading advisories and creating a response plan require no account.
When a vendor publishes an alert, the team responsible still has to determine whether its systems are affected. It may also need to compare the vendor’s notice with attack reports and guidance from a national computer security incident response team, or CSIRT. Radar brings those sources, their dates and Oktsec’s recommended actions into one incident record, including the implications for AI agents.
What the evidence establishes
Radar distinguishes an exploit demonstrated by researchers from attacks observed outside a test. It also records whether a fix is available and which claims have supporting sources. Readers can inspect those sources and the dates they were checked.
The sources answer different questions. The U.S. cybersecurity agency CISA’s Known Exploited Vulnerabilities catalog records vulnerabilities known to have been exploited. FIRST EPSS estimates the chance that a vulnerability will be exploited in the next 30 days; it is not the chance that your organization will be attacked. OSV provides vulnerability records tied to open source packages and versions.
Regional coverage draws on CSIRT Panamá, CERT-PY in Paraguay and CISC Brasil. Notices are matched using CVE identifiers: the reference numbers assigned to individual vulnerabilities. A matching notice appears alongside the incident, with its original title and link.
This lets a team compare the vendor’s guidance with notices from regional authorities. The publisher’s country identifies the source, not the location of attacks.
An “Act now” priority is Oktsec’s recommendation to review the issue promptly, based on the evidence and required action. Radar does not scan your systems. A low forecast or an absence of confirmed attacks is not a reason to skip checking affected versions.
Find a product and record your response
Start in Advisories and search for a product, CVE or keyword. Open its record to follow three steps:
- Read the advisory. Understand the problem, the evidence and who should check their systems.
- Check affected systems. Compare the running products and versions with the published guidance.
- Build a response plan. Record whether the issue applies to your environment, name the system and responsible team, and track each action. If you cannot establish whether it applies, choose “Needs verification”.
Take PHP2Shell. PHP disclosed the original two vulnerabilities on October 21 and published fixes for the supported release branches. AWS reported an exploitation attempt from October 17 in MadPot, its threat monitoring system, four days before public disclosure. For a team running an affected PHP version, that earlier date defines where the investigation should begin, even after installing the fix.
The checklist calls for preserving and reviewing host activity from at least October 17, including credentials accessible to the PHP process. It also points to PHP’s separate October 23 guidance on session upload progress, a feature used to track file uploads. That later issue requires its own configuration checks; the original fixes do not settle it.
The plan records your decision, action status, notes and source links. It saves in the current browser; it does not sync with colleagues or go to Oktsec. Download the Markdown file to keep a copy or attach it to a ticket, especially before clearing browser data. Marking an action done records your team’s work; it does not independently verify the fix.
When a saved record’s advisory revision changes, Radar flags it for reassessment and retains the previous notes. That gives the team a reason to revisit a decision it has already made.
What an incident means for AI agents
An agent depends on software libraries, service credentials and tools that can be affected by the same incidents as other applications. Radar explains those connections where the evidence supports them.
In LiteLLM 1.107.0, malicious release artifacts included files that could execute when Python started. The vendor’s response guidance includes replacing reachable model provider keys and other credentials. For teams running agents, that means checking the credentials and authentication files accessible in the same environment. Removing the package alone does not revoke a stolen key.
Brotli illustrates a different path. A vulnerable decoder may sit in a runtime, HTTP client or proxy. Envoy’s advisory applies to deployments configured for Brotli decompression. In an agent deployment, that could include a proxy in front of a Model Context Protocol (MCP) server that connects agents to tools, or a tool fetching compressed responses. The relevant check is whether untrusted data reaches the affected decoder.
Follow updates and reuse the source data
Radar’s methodology is public. Each incident includes a dated editorial record of published updates, so readers can see how the guidance has changed.
The site also publishes incident records and supporting source data as JSON, alongside RSS, JSON Feed and reading guidance for agents. Use RSS to follow updates in a feed reader, or JSON records to reference incidents in your own tools. The agent guide explains how to read the records and interpret their evidence.
Coverage is selected, not exhaustive. Radar follows incidents relevant to infrastructure, AI environments and the region, and distinguishes unverified claims from confirmed evidence.
Ask Oktsec to review your environment
“Talk to Oktsec” opens an assessment request that carries the incident with it. Use it when you need help checking exposure, verifying fixes or reviewing credentials an incident could reach. Scope, access, fees and timing are agreed before work begins.