A Lithuanian Cyber Incident Worth Learning From

In June 2026, Lithuania's State Health Care Accreditation Agency, VASPVT, disclosed a cybersecurity incident affecting one of its information-system subsystems. The incident is worth examining because it shows how a well-protected main application can still be exposed through a connected third-party component.

According to VASPVT, the incident took place on 7–8 June 2026 and was detected during the night of 8–9 June. The affected subsystem used Apache Superset, an open-source platform for data analysis and visualisation. Attackers exploited a vulnerability in that component to gain unauthorized access.

The main system itself used centralized Single Sign-On (SSO), with users normally authenticating through Lithuania's Electronic Government Gateway. The affected administrative and reporting subsystem, however, could be reached through the vulnerable Superset component. In practical terms, the attackers did not need to defeat the main authentication mechanism because another connected tool provided a different route into the environment.

What data may have been accessible?

VASPVT initially reported that the unauthorized access could potentially have exposed:

• up to 62,203 records containing healthcare professionals' professional and contact information;
• up to 156 records relating to institution administrators;
• up to 365 records relating to professional competencies;
• system and technical metadata.

The agency later clarified an important point: investigators had not established that the data had actually been extracted, stolen or disclosed to third parties. What was confirmed was unauthorized access and an attempt to reach the data.

That distinction matters. Unauthorized access does not automatically mean that every accessible record was downloaded, but it still demonstrates that someone reached a part of the infrastructure they were not supposed to reach.

The response happened quickly

After detecting the incident, VASPVT said it disconnected external access, disabled local access, deactivated access tokens, disconnected Apache Superset from the information system, informed the responsible authorities and began further investigation and monitoring. According to the agency, the vulnerability was contained within several hours.

This part of the incident is just as useful as the vulnerability itself. Cybersecurity is not only about preventing every possible intrusion. Detection and response speed also matter. A weakness that remains unnoticed for months creates a very different level of risk from one that is detected and isolated quickly.

The system had already been security-tested

One of the more interesting details is that VASPVT stated its information systems had undergone penetration testing and used secure authentication mechanisms.

That does not necessarily mean the penetration testing failed. A penetration test normally examines a defined scope at a particular point in time. If new components, integrations or supplier-managed tools are added later, the real attack surface changes.

A customer portal might be tested in January. A reporting dashboard could be added in February. A supplier could deploy another integration in March. A vulnerability could then be discovered in one of those components in April. By June, the environment may differ substantially from what was originally tested.

The lesson is simple: the security of the main application and the security of the entire environment are not necessarily the same thing.

The supplier connection matters

The affected component was part of a solution involving an external supplier, which makes the incident particularly relevant to companies that outsource parts of their IT environment. (vaspvt.lrv.lt)

Modern companies depend on external software and service providers for hosting, e-commerce, CRM, analytics, payments, authentication, customer support and many other functions. That is normal, but every connected service can become part of the company's effective security perimeter.

A company may have a secure customer portal but an exposed administrative dashboard. Its own developers may keep the application patched while a third-party component falls behind. Employees may use strong authentication while an integrated tool follows a different access path.

From the customer's point of view, there is rarely much difference between “our software was vulnerable” and “our supplier's software was vulnerable.” Both can result in the same data exposure, service disruption and loss of trust.

Lithuania's wider cybersecurity picture

The incident also fits into a broader pattern visible in Lithuania's cybersecurity statistics. Lithuania's National Cyber Security Centre reported that in 2025:

• 64% of assessed systems were identified as vulnerable;
• more than 106,000 leaked credentials associated with Lithuania were discovered;
• 1,551 social-engineering incidents were registered;
• social engineering represented 54% of registered cyber incidents.

In 2024, NKSC registered 3,874 cybersecurity incidents, a 63% increase from 2023, and identified roughly 6,700 cybersecurity vulnerabilities during the year.

Lithuania's State Data Protection Inspectorate also received 223 personal-data breach notifications in 2025, affecting approximately 1.25 million data subjects. Human error accounted for 58% of reported breaches, while cyber incidents accounted for 29%.

These numbers do not suggest that every organization is constantly under sophisticated attack. They do show that vulnerable systems, compromised credentials, social engineering and data-security incidents are common enough to be treated as ordinary business risks.

What can any business learn from this?

This incident gives a very clear example of a problem that applies to almost every modern organization. The useful questions are fairly universal:

• What systems are actually reachable from the internet?
• Which third-party applications and open-source components are connected to them?
• Are administrative and reporting tools tested as well as the main application?
• Who is responsible for patching each component?
• Has the environment changed since the last security test?
• How quickly would unauthorized access be detected?
• Which suppliers can access business or customer data?

The important point is that modern systems do not stay static. Every new integration, supplier, dashboard or service can change the real attack surface.

The side door matters as much as the front door

What makes this incident useful is not Apache Superset itself. The important part is the pattern: the main login can be secure, the primary application can be penetration-tested, and another connected component can still expose a different route into the environment.

For businesses, cybersecurity therefore should not stop at “our website was tested” or “we use secure authentication.” A better question is: “What can someone reach from the internet today, including the systems, integrations and tools connected to our main application?”

That is the gap continuous security testing is intended to reduce.

At Grawlr, we continuously test websites and APIs against known vulnerabilities and real-world attack patterns, helping companies discover exposed weaknesses as their systems change.

Verify your security. Validate your suppliers. Simplify compliance.