Your IT Support Tool Has a Master Key. Someone Just Found It.
Your IT provider can access your computers remotely. That is the point. When something breaks, they connect, fix it, and disconnect. You trust that access because it is protected by passwords, multi-factor authentication, and the assumption that the software doing the connecting is secure.
That assumption has a crack in it. As of 29 June 2026, CISA confirmed active exploitation of CVE-2026-48558 in SimpleHelp, remote support software used by IT managed service providers globally. The flaw bypasses authentication entirely. In specific configurations, it bypasses MFA as well.
This is not a vendor press release. This is CISA’s Known Exploited Vulnerabilities catalogue: the list of flaws that attackers are actively using right now, against real targets.
What SimpleHelp Is and Why It Matters to Small Businesses
SimpleHelp is a remote support platform. It allows technicians to connect to client machines, run commands, transfer files, and administer systems remotely. If you have ever called your IT provider and had them “take over” your screen to fix a problem, there is a good chance they were using something like SimpleHelp to do it.
That level of access is, by design, comprehensive. A technician session gives the holder the ability to operate your machine as though they are sitting in front of it. They can read files, install software, access connected network resources, and move laterally across your infrastructure.
The vulnerability does not affect your machine directly. It affects the SimpleHelp server your IT provider runs. But the consequence lands on you.
What the Vulnerability Actually Does
CVE-2026-48558 is an authentication bypass in SimpleHelp’s OIDC (OpenID Connect) authentication flow. OIDC is a standard used for identity verification: it is how many systems confirm that the person logging in is who they claim to be.
In a vulnerable SimpleHelp configuration, identity tokens submitted during login are accepted without verifying their cryptographic signature. In plain terms: the system is supposed to check that the login token is genuine and has not been tampered with. It is not doing that check.
The result is that an attacker who is not a legitimate technician can forge a token containing arbitrary identity claims and submit it to the SimpleHelp server. The server accepts it. The attacker receives a fully authenticated technician session.
In some configurations, this also bypasses multi-factor authentication. MFA is supposed to be the second lock on the door. This flaw, depending on how SimpleHelp is deployed, removes both locks simultaneously.
No password required. No MFA prompt. No notification to your organisation. Full technician access.
The Supply Chain Problem This Exposes
This is the supply chain risk that the NCSC has been flagging for years, made concrete.
Your organisation may have excellent perimeter defences. Your firewall is configured. Your staff have been trained not to click suspicious links. Your own systems are patched. None of that matters if an attacker gains technician-level access through your IT provider’s tooling.
The attack surface is not your front door. It is the service entrance your support provider uses. That entrance exists on your provider’s infrastructure, not yours. You cannot patch it. You cannot monitor it directly. You are dependent on your provider having done so.
For UK SMBs using managed service providers, this is a precise illustration of why supplier security questionnaires are not compliance theatre: they are the mechanism by which you establish whether the people with privileged access to your systems are maintaining that access responsibly.
If your IT provider cannot tell you whether they use SimpleHelp and whether they have applied the patch for CVE-2026-48558, the conversation you need to have is not a technical one. It is a contractual one.
A Second Issue Worth Noting: CVE-2026-55200 in libssh2
Separately from the SimpleHelp situation, a public proof-of-concept exploit has been released for CVE-2026-55200, a critical vulnerability in libssh2. SSH (Secure Shell) is the protocol used for secure remote connections to servers. libssh2 is the underlying library that many applications use to implement SSH connectivity.
The flaw allows a malicious or compromised SSH server to trigger memory corruption on a connecting client. The practical attack scenario: if you connect to a server that has been compromised, that server can potentially execute code on your machine rather than the other way around.
The release of a public proof-of-concept is significant because it transforms a theoretical risk into a practical one. Security researchers and attackers alike now have working code they can adapt.
libssh2 is embedded in a wide range of software: file transfer tools, deployment systems, backup software, developer tooling. If any of those applications in your environment rely on libssh2 and have not been updated to a version that patches CVE-2026-55200, the exposure is present.
This one is less immediately actionable for a non-technical business owner than SimpleHelp. The question to ask your IT provider or internal IT contact is: do any systems or applications we rely on use libssh2, and are they patched?
How This Gives You an Edge
Most small businesses do not ask their IT providers difficult questions. They pay a monthly fee, assume things are being handled, and find out they were wrong when something goes catastrophically wrong.
The businesses that take a different approach, the ones that ask specifically about patching timelines, ask which remote access tools are in use, and ask what the process is when a critical vulnerability is disclosed, those businesses create accountability that passive clients do not.
If you are in a competitive market where clients are asking about your security posture, being able to say “we actively monitor our supply chain for exactly these kinds of disclosures and have verified our provider’s response” is a meaningful differentiator. It is verifiable. It is specific. It is the opposite of checkbox theatre.
More concretely: if your IT provider is asked about CVE-2026-48558 today and cannot answer clearly, you have learned something valuable about the quality of your managed service. That knowledge is worth acting on before an attacker acts on the vulnerability.
Making the Business Case
Three points for any conversation about resourcing this properly:
The risk is third-party, which makes it harder to manage internally. You cannot patch your supplier’s infrastructure. You can only require accountability from them. That requires a contract with teeth, not a handshake agreement.
The consequences of a compromised technician session are severe. An attacker with full remote access to your network can exfiltrate client data, deploy ransomware, establish persistence, and move laterally before any alert fires. The ICO will not accept “our IT provider was breached” as a complete answer to a data breach notification.
Verifying your supplier’s patch status costs almost nothing. A single email or phone call asking for confirmation that CVE-2026-48558 has been remediated takes ten minutes. The cost of not asking is potentially unbounded.
What to Do Before the End of This Week
1. Ask your IT provider directly. Send a written message today: “Do you use SimpleHelp in your environment or for connecting to our systems? Have you applied the patch for CVE-2026-48558? Please confirm in writing.” Written confirmation matters. It creates a record.
2. Review your IT support contract. Does it include any obligation on the provider to notify you when critical vulnerabilities affecting their tooling are disclosed? If not, that is a gap worth addressing at renewal.
3. Ask about privileged access management. How many people at your IT provider have the ability to connect to your systems? Under what circumstances? Is that access logged? Can you request those logs?
4. Check for libssh2 exposure. Ask your IT contact or internal administrator: do any of our systems, applications, or backup tools use libssh2? If yes, are they on a version that addresses CVE-2026-55200?
5. If your provider cannot answer these questions clearly, treat that as a risk finding. Not a reason to panic, but a reason to set a deadline for a satisfactory answer and consider your options if one is not forthcoming.
The NCSC’s supply chain security guidance is clear on this: you are responsible for understanding the security posture of the organisations that have privileged access to your systems. “We didn’t know” is not a defence. It is an abdication.
The data about what is being exploited right now is public. CISA publishes it. The question is whether you are using it.
Before you go: follow the show wherever you listen, leave a rating or review, drop a comment with your thoughts, and share this with someone who would find it useful. If your IT provider just answered your question about SimpleHelp clearly and quickly, share it with them as a thank-you. If they could not, share it with whoever signs their contract.