Quick take: CISA’s Known Exploited Vulnerabilities catalog added a fresh July 2026 cluster that should push patch triage back to the top of the small-business security agenda. The newest entries include Microsoft SharePoint remote-code-execution and privilege-escalation issues, Fortinet FortiSandbox command-injection flaws, Oracle E-Business Suite exposure, SonicWall SMA appliance issues, and several website/CMS plugin vulnerabilities. If your team uses any of these systems directly—or depends on a vendor or MSP that does—this is the week to verify patch status instead of waiting for the next quarterly maintenance window.
What happened in July 2026?
The U.S. Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities catalog, commonly called KEV, to identify vulnerabilities that have evidence of active exploitation. In the latest July 2026 feed, several entries stand out for small and midsize organizations because they touch systems that often sit close to sensitive files, identity workflows, remote access, web publishing, or security operations.
The recent KEV entries include:
- CVE-2026-58644 — Microsoft SharePoint: described by CISA as a deserialization of untrusted data issue that can allow unauthorized remote code execution over a network.
- CVE-2026-56164 — Microsoft SharePoint Server: described as missing authentication for a critical function that can allow unauthorized privilege escalation over a network.
- CVE-2026-25089 and CVE-2026-39808 — Fortinet FortiSandbox: OS command-injection vulnerabilities that can allow unauthorized command or code execution under affected conditions.
- CVE-2026-46817 — Oracle E-Business Suite: an improper privilege-management issue that CISA says can allow compromise through HTTP network access.
- CVE-2026-15409 and CVE-2026-15410 — SonicWall SMA1000 appliances: server-side request forgery and code-injection issues affecting remote-access infrastructure.
- Joomla and website builder/plugin issues: recent KEV items also include vulnerable forms, page builders, and CMS components with dangerous file-upload or remote-code-execution paths.
For enterprise security teams, this becomes a standard emergency-change process. For a small business, the danger is different: the vulnerable system may be managed by a part-time IT provider, a web agency, a SaaS vendor, or an internal power user who does not think of that tool as critical infrastructure.
Why this matters for small businesses
Small organizations often believe KEV is only for federal agencies or large enterprises. That is a mistake. KEV is useful because it filters the endless vulnerability stream down to issues with known exploitation. In plain English: someone has already moved beyond theoretical risk.
That does not mean every small business is affected by every CVE. A bakery with no SharePoint server and no Fortinet appliance should not panic about SharePoint or FortiSandbox. But the right lesson is to ask a faster question: which internet-facing, identity-related, file-sharing, remote-access, website, or security systems do we actually depend on?
The July 2026 set is especially relevant because it crosses five common risk zones:
- Collaboration and file platforms: SharePoint-style systems hold documents, customer records, contracts, HR files, and internal knowledge.
- Security appliances: sandboxing, firewall, VPN, and remote-access products can become high-value footholds when they are exposed and unpatched.
- Business applications: ERP and workflow platforms may connect to finance, customer, supply-chain, or operations data.
- CMS and website plugins: file-upload and page-builder bugs can turn a public website into a malware host, phishing page, or pivot point.
- Identity-adjacent services: remote access and federation tools sit close to authentication, session tokens, and privileged administration.
The practical patch-priority order
If you have a tiny team, do not try to patch everything in the same hour without context. Use a risk-based queue. Start with systems that are internet-facing, exploitable without authentication, already known to be exploited, or connected to identity and sensitive data.
1. Exposed SharePoint and collaboration servers
If your organization runs on-premises or self-managed SharePoint, confirm whether the July 2026 SharePoint KEV entries apply. Prioritize systems accessible from the public internet, systems used by external partners, and systems holding sensitive documents. If a vendor or MSP manages SharePoint for you, ask for the specific CVEs, patch status, mitigation status, and whether logs were reviewed for suspicious access.
2. Security appliances and remote-access infrastructure
Fortinet FortiSandbox and SonicWall SMA devices are exactly the kinds of tools small teams can forget after setup. They may be “security products,” but they still need emergency patching when exploitation is known. Confirm firmware/software versions, management-interface exposure, administrator accounts, and whether remote access is restricted by IP, VPN, or identity controls.
3. Business applications reachable over HTTP
Oracle E-Business Suite exposure should trigger a review of externally reachable business systems, not just Oracle-specific patching. Any HTTP-accessible business app that touches finance, customer records, procurement, or employee data deserves higher priority than a low-risk desktop utility.
4. Public websites, CMS plugins, and page builders
The KEV feed continues to show a pattern: website plugins and builders become a reliable attack surface when file uploads or access controls fail. Even if your website is “just marketing,” attackers can use it for spam, redirects, credential harvesting, malware delivery, or reputational damage. Check WordPress, Joomla, page builders, forms, backup plugins, and any tool that allows file uploads.
A 60-minute checklist for owners and lean IT teams
Use this fast checklist today if you are not sure whether your business is exposed.
| Step | What to verify | Evidence to keep |
|---|---|---|
| Inventory | Do we run SharePoint, Fortinet FortiSandbox, SonicWall SMA, Oracle E-Business Suite, Joomla, WordPress, or vulnerable page-builder/form plugins? | Product, version, owner, hosting location |
| Exposure | Is the system reachable from the public internet or only behind controlled access? | External URL/IP, firewall rule, access policy |
| Patch | Is the vendor fix installed, or has a documented mitigation been applied? | Patch date, version, change record |
| Logs | Were access logs, admin logins, file uploads, and suspicious requests reviewed? | Log window checked, anomalies found, next action |
| Hardening | Can admin panels be restricted, MFA enforced, and stale accounts removed? | Access-control changes and account review |
How to ask your MSP or web agency the right questions
If a third party manages your systems, do not ask a vague question like “are we secure?” Ask for specifics:
- “Do any of our managed systems match the July 2026 CISA KEV entries for SharePoint, Fortinet FortiSandbox, Oracle E-Business Suite, SonicWall SMA, Joomla, or CMS plugins?”
- “Which systems are externally reachable?”
- “What versions are we running today?”
- “Which patches or mitigations were applied, and when?”
- “Did you review logs from before and after patching for signs of exploitation?”
- “Are admin interfaces protected by MFA and limited network access?”
That final log-review question matters. Patching closes a door; it does not prove nobody walked through it yesterday.
Where AI governance fits into patch response
AI tools are changing patch management in two ways. First, teams are connecting AI assistants to documents, tickets, repositories, CRMs, and cloud tools. Second, staff may paste system details or incident notes into consumer AI tools when under pressure. Use the NIST AI Risk Management Framework as a reminder to govern AI use around security operations, and the OWASP Top 10 for LLM Applications as a practical reference for risks such as prompt injection, sensitive-information disclosure, and excessive agency.
For small businesses, the simple rule is: do not let AI tools become an unmanaged shortcut during an incident. Use them to summarize public advisories, draft internal checklists, or organize notes—but keep credentials, customer data, log exports, and private architecture details in approved systems.
Recommended 7-day action plan
Day 1: identify exposed systems
List externally reachable collaboration servers, VPN/remote-access tools, security appliances, business apps, and website/CMS stacks. Include vendor-managed systems.
Day 2: map against KEV
Check whether any products match the CISA KEV entries. Do not stop at exact product names; ask vendors whether bundled components or managed services are affected.
Day 3: patch or isolate
Apply vendor patches where available. If immediate patching is impossible, reduce exposure: restrict admin access, disable vulnerable modules, block public access, or place access behind VPN/zero-trust controls.
Day 4: review logs
Look for unusual uploads, new admin users, unexpected configuration changes, suspicious HTTP requests, failed login bursts, and outbound connections. Expand the time window if anything looks abnormal.
Day 5: rotate high-risk credentials
If a vulnerable system held credentials, sessions, API keys, or admin access, plan rotation. Prioritize privileged accounts and integrations.
Day 6: document owner and cadence
Every exposed system needs an owner, a patching cadence, and an escalation path. If “nobody owns it,” the risk will return.
Day 7: turn the lesson into policy
Create a lightweight KEV response process: weekly KEV review, monthly external-asset review, emergency-patch criteria, and a vendor-question template.
Internal reading on CyberTrendLab
If this briefing applies to your team, pair it with our practical guides on ransomware prevention for small businesses, phishing prevention for remote teams, building a small-business security stack, and least privilege for AI agents.
FAQ
Does every CISA KEV entry apply to my business?
No. KEV is a prioritization signal, not proof that your environment is affected. Start by mapping products and exposure, then patch or mitigate the entries that match your stack.
What should be patched first?
Prioritize internet-facing systems, unauthenticated remote-code-execution paths, identity or remote-access infrastructure, and systems holding sensitive data. Website plugin issues also deserve quick attention when they allow file upload or code execution.
Is patching enough?
Not always. For known exploited vulnerabilities, patching should be paired with log review, account review, and credential rotation where exposure could have affected secrets or privileged access.
Should small businesses monitor the KEV catalog?
Yes. A weekly KEV review is a low-cost way to identify vulnerabilities that are actively exploited in the wild. It helps small teams focus on the issues most likely to matter.
Bottom line
The July 2026 KEV additions are a useful wake-up call because they are not confined to one vendor or one kind of system. Collaboration platforms, security appliances, business apps, remote-access tools, and CMS plugins all appear in the same operational patch story. Small businesses do not need enterprise bureaucracy to respond well—but they do need ownership, exposure checks, fast patching, and proof that someone looked for signs of compromise.
