Loxone Cyberattack: CRM and Applicant Data Copied, What Installers Do

On 18 October 2026, Austrian building automation maker Loxone detected a cyberattack on internal systems. Data was copied mainly from its CRM and applicant management, which may include partner contacts, support requests and applicant records. Loxone says Miniservers, Remote Connect and Exosphere are unaffected. Installers should expect targeted phishing and verify every request.

This post sets out what Loxone itself has published, separates it clearly from what the attackers claim, and then turns to the people most exposed by this kind of breach: the electrical installers and integrators whose names, companies and support history sit in a vendor CRM. The practical part draws on Loxone's own documentation for Miniserver users, rights, Remote Connect and external access, so you can tidy up the installations you look after while the investigation continues.

A word on tone. Loxone detected the attack, isolated systems, brought in outside forensic specialists, informed authorities, published a running update page and restored services in stages over four days. Nothing here speculates about its internal setup. The lessons are written for any vendor that runs a partner channel, and for any installer whose details live in one.

What happened

According to Loxone's incident page at security.loxone.com, the company detected a cyberattack on internal company systems on Sunday 18 October 2026. Its first published update, timed 13:01 on 19 October, says the affected internal systems include its CRM with partner data and its applicant data, that affected systems were isolated, and that the attack path had been identified and confirmed together with external forensic experts.

Loxone says it will not describe the attack path publicly for security reasons. Reporting by the French site cyberattaque.org, by QUASA and by Dysruption Hub all cite an interview that Loxone Electronics president Florian Wöss gave to the Austrian broadcaster ORF, in which he said the attack came through one of the company's web servers. Loxone's own written statement does not repeat that, and no source names a vulnerability or misconfiguration.

The incident became visible to the public when several pages on loxone.com were replaced with a ransom message. According to cyberattaque.org, the message came from a group calling itself "Samurai" and said that 201.6 GB had been copied and encrypted, threatening to publish the archive unless Loxone negotiated. heise online reported the group's claim as about 200 GB. Loxone has not confirmed any volume.

What Loxone says was taken

Per the incident page, data was copied from internal systems, mainly the CRM and applicant management. It may include:

• contact details of business partners, which heise reports Loxone describes as mainly electrical installation companies
• support requests
• applicant data submitted during job applications

Loxone says the full scope is still under review and that affected individuals will be notified as required by law. In a statement quoted by heise, Loxone also said its internal CRM and the website's database "have been corrupted." Update 5 on the incident page adds that databases the attackers had encrypted were decrypted for analysis.

What Loxone says was not affected

This is the part installers and building owners will want first, so here it is in Loxone's own terms, taken from the incident page and the 19 October statement on loxone.com:

• Customer installations and Miniservers are not affected. Miniservers run locally with their own credentials and control building technology on site.
• Remote Connect and Exosphere are not affected.
• LOXONE.com accounts show no indication of compromise.
• No credit card or bank data was obtained.
• Partner Portal login credentials are held in separate infrastructure.
• The update infrastructure and software development systems were not affected; the codebase was confirmed as not compromised, and the build pipeline was rebuilt as a precaution.
• Software bearing the Loxone signature is confirmed genuine.
• There have been no security incident reports from customer installations worldwide since the attack.

heise adds Loxone's statement that user and access data are stored only locally on each Miniserver and that Loxone does not host a database of login credentials for customer installations, so the attackers could not have accessed them. The homepage notice puts it in one line: the Miniserver architecture "has relied on local users, with no central point of attack."

Timeline

Times below are copied as printed on Loxone's incident page. The page does not state a time zone; Loxone is headquartered in Kollerschlag, Austria, so central European summer time is likely but not stated. Other rows are at day level unless a source gives a time.

What changed since first reports

The first reports on 19 October rested on the defacement and a short statement. Four things have firmed up or shifted since.

First, the scope of affected systems is clearer. Loxone now names the CRM and applicant management specifically, and its later updates mention the Partner Portal, which was hosted on an affected server and was temporarily unavailable, and the website database.

Second, the encryption claim is partly confirmed. The attackers' note said data was copied and encrypted. Loxone's Update 5 confirms that databases had been encrypted by the attackers and that Loxone decrypted them for analysis. It does not confirm the 201.6 GB figure or say what share of data was encrypted.

Third, Loxone has published a firm list of what was not reached: the update infrastructure, software development systems and codebase, with the build pipeline rebuilt anyway. For a building automation vendor, that is the most important statement in the whole incident, because a tampered update channel would reach every installation.

Fourth, the phishing angle is now explicit. Update 6 says Loxone will inform people who received an email from the attackers, and the incident page names two lookalike sender domains to watch for. That tells you the stolen contact data has already been used, at least once, to reach people directly.

Technical details

There is no CVE, no malware hash and no indicator list in any primary source for this incident. Loxone has chosen not to publish the attack path. What follows is every concrete, defender useful value that a fetched source does publish, attributed.

Incident facts

Attacker claims, unconfirmed

These come from the defacement and from samples the group posted. Loxone has not confirmed any of them, and some it has disputed.

Two points about the serial number claim deserve care, because they are where an installer's worry naturally goes.

A Miniserver serial number is not a secret in Loxone's design. Loxone's Remote Connect documentation shows that a Miniserver is reached at an address of the form https://dns.loxonecloud.com/504F94000000, where the last part is the serial number, and the External Access article uses the same pattern for Cloud DNS. Anyone who has ever been sent a Remote Connect link has seen one. Access still requires a valid user and password on the Miniserver itself, which Loxone says it never holds centrally.

A list that pairs serials with project names would still be useful to an attacker as a target list, and as a prop for convincing phishing ("we need to check Miniserver 504F94... at the Smith project"). That is the realistic risk, and it is the same risk the stolen CRM data creates even if no serial list exists. The rest of this post treats it that way.

Loxone platform values defenders need

These come from Loxone's own documentation, fetched for this post.

Why a vendor CRM breach is a supply chain story

Building automation sells through a channel. The vendor makes the Miniserver and the software; certified partners, mostly electrical installers, design, program and maintain the systems in homes, offices and commercial buildings. The vendor's CRM is the map of that channel: which companies install the product, who the technical contacts are, which regions they work in, and what they asked support about.

That map is valuable to an attacker for reasons that have nothing to do with the vendor's own systems.

• It makes phishing credible. An email that names the installer's company, references a real support case and comes from a domain one letter away from the vendor's is far more convincing than a generic lure.
• Support history can contain operational detail. Loxone's advice, discussed below, explicitly tells people never to put passwords or API keys into support requests, and QUASA reports Loxone checked whether installation credentials had ever been sent in plain text and contacted the relevant partners. That is a sign the vendor considered the possibility. It is not a statement that credentials were in the stolen data.
• Installers hold the keys. The people in the CRM are the ones who have administrator access to many Miniservers, often via Loxone Config with remote configuration enabled. Compromising one installer's laptop or mailbox can be worth more than compromising one building.
• Applicants are a separate population. Applicant records typically include CVs, contact details and sometimes identity documents. Those people did not choose to do business with the vendor at all, and they need their own notice and their own advice.

Every vendor with a partner channel carries the same exposure: distributors, resellers, managed service providers, systems integrators. The defensive lessons apply well beyond building automation.

Who is affected

What to do now: a checklist for Loxone partners and installers

The steps below follow Loxone's own advice from the incident page and its knowledge base. None of them require waiting for the investigation to finish.

1. Treat any Loxone themed request as unverified until checked

Loxone states that it never asks for passwords by email, phone, SMS or social media, and that its bank details have not changed. Build a simple rule in your office: any request for credentials, remote access, payment or a change of bank details that claims to come from Loxone gets verified by calling a number you already have, not one in the message.

Check the sender domain character by character. Loxone names @loxon.com and @luxone.com as lookalikes seen so far. Others will follow. The real domain is @loxone.com.

2. Flag lookalike domains in your mail system

If your company uses Microsoft 365, an Exchange Online mail flow rule can tag mail from known lookalikes so staff see a warning in the subject line. Run this in Exchange Online PowerShell after Connect-ExchangeOnline:

New-TransportRule -Name "Loxone lookalike sender warning" `
  -SenderDomainIs "loxon.com","luxone.com" `
  -PrependSubject "[CHECK SENDER] " `
  -SetAuditSeverity Medium

To see whether anyone in your company has already received such mail in the last ten days, use message trace in the Exchange admin center, or in PowerShell:

Get-MessageTraceV2 -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date) |
  Where-Object { $_.SenderAddress -match '@(loxon|luxone)\.com$' } |
  Select-Object Received, SenderAddress, RecipientAddress, Subject

In Google Workspace or Gmail, a search does the same job:

from:(@loxon.com OR @luxone.com) newer_than:14d

Update both lists as new lookalikes appear. A rule with two domains is a stopgap, not a filter.

3. Check the authentication results on any message you are unsure of

Real mail from a domain should pass the domain's published sender checks. You can see what a domain publishes with dig:

dig +short TXT loxone.com | grep -i spf
dig +short TXT _dmarc.loxone.com
dig +short MX loxone.com

Then open the suspicious message's full headers and look at the Authentication-Results line. A message that claims to be from Loxone but shows dmarc=fail, or comes from a different domain entirely, should be reported, not answered. A pass does not prove a message is safe, since a compromised real mailbox would pass too, which is why step 1 still applies.

4. Find credentials you may have sent in support requests

Loxone's incident page says never to share passwords, API keys or other credentials in plain text, including in support requests, and to change any credentials that were previously sent over insecure channels.

Search your own sent mail for anything that went to Loxone support with a credential in it. For a mailbox exported as mbox, a rough first pass is:

grep -n -i -E "support@loxone\.com" -A 200 Sent.mbox |
  grep -i -E "passwor|kennwort|passwort|admin:|api.?key|token"

In Outlook or Gmail, search sent items for to:support@loxone.com and read the hits. For every site where a credential left your office in plain text, change it on the Miniserver and record that you did.

5. Give every person their own Miniserver user

Loxone's advice is to create individual user accounts on the Miniserver instead of sharing passwords. In Loxone Config:

1. Create a user for each person who needs access, including each of your technicians, rather than sharing admin.
2. Put them in groups and grant only the rights each needs. Loxone's knowledge base identifies Loxone Config (full administrator), FTP and User Management as the rights to restrict most tightly.
3. Use Show All Permissions to see the effective rights for each user and the reason for each.
4. Remember that an explicit deny anywhere in the group chain overrides every allow, which makes deny useful for locking a technician out of a room or function.
5. Change the admin password to a strong, unique one, and store it in a password manager the building owner can reach, not in an email.

Loxone Config 12.1 and later can Export Users to CSV, which is handy for an audit of a large site. Treat that file as sensitive and delete it when done.

6. Make service access time limited

Loxone recommends time limited accounts for service visits and regular removal of unused accounts. The Status section of a user in Loxone Config lets you enable or disable the user and limit access to a specific period. For a one off service call, create a user that expires after the visit. For door access, Access Schedules under Manage Permissions restrict when an NFC tag or code works.

At the end of a job, disable the user rather than leaving it for next time. A disabled account that someone has to re enable is a small speed bump for you and a large one for an attacker.

7. Review external access on each installation

Loxone's External Access and Remote Connect articles give a clear order of preference:

1. Remote Connect for current Miniservers. It needs no port forwarding, is encrypted, and Loxone says it is not affected by this incident.
2. A VPN where the site has higher security requirements.
3. Manual port forwarding only if neither is possible, and then HTTPS only, with the HTTP port set to 0, an external port in 1024 to 49151 that is not on the common port lists, and never a DMZ.

From outside the site's network, you can confirm that no unexpected Miniserver port answers on the site's public address. Use only addresses you are responsible for:

# Replace with the site's public IP and the port you expect to be closed
curl -skI --max-time 5 https://203.0.113.10:7878/ | head -n 1
nc -vz -w 5 203.0.113.10 80

If port 80 or a forwarded HTTP port answers and the site uses Remote Connect, remove the forward on the router.

Also check whether remote configuration over the internet is switched on. It is a separate opt in. If your team does not configure that site remotely, turn it off. If it does, make sure only named technician accounts with the Loxone Config right can use it.

8. Keep firmware and Config current, and move to 2FA

Loxone advises always running the latest Loxone Config, firmware and apps. Update signing has been in place since 2020 for Miniservers on 11.1 or later, and Loxone's incident page confirms that software bearing the Loxone signature is genuine and that the update infrastructure was not affected. In plain terms: updating is safe, and Loxone's FAQ says so directly.

Loxone Config 17.2.10.21 adds two factor authentication and was in testing as of 22 October, with internal test versions for the Partner Portal and Exosphere. Plan to enable 2FA on every Loxone account in your company as soon as it is generally available for your products.

9. Watch for factory default windows on new installs

Since firmware 13.1, a Miniserver in factory state accepts Remote Connect logins with admin/admin for 20 minutes after startup, according to Loxone's Remote Connect article. That is a convenience for commissioning. Set a strong admin password as the first step on every new or reset Miniserver, before you leave it powered and connected unattended.

10. Brief your team and your customers

A two minute note is enough. Tell staff that Loxone has had a breach of partner contact and support data, that Loxone will never ask for passwords, that bank details have not changed, and that any odd request gets a call back on a known number. Tell building owners the same, and that Loxone says their installation is unaffected. Customers who hear that from their installer first are less likely to believe a phishing email that says otherwise.

What to do now: for job applicants

• Wait for Loxone's direct notice. Loxone says affected individuals will be informed as required by law; QUASA reports that applicants cannot yet tell whether their applications were copied.
• Treat unsolicited messages about your application, an interview or a document request with care, especially if they ask you to log in somewhere or send identity documents.
• If you reused a password from an application portal anywhere else, change it there.
• Under the EU's data protection rules you have a right of access to the personal data a company holds about you. You can ask Loxone what it held from your application.

What vendors with a partner channel can take from this

These are general practices for any company that runs a CRM full of partners, not a judgement on Loxone.

Keep public web servers away from internal data

If, as Wöss told ORF, entry came through a web server, the question every vendor should ask itself is: what can my public web servers reach? A public facing site should not have a network path or service account that reaches the CRM, the applicant database or HR systems. Put middleware between them with narrow, authenticated APIs, and log every bulk read. Loxone's own response, rebuilding the CRM middleware from scratch and rotating all authentication, shows where the sensitive joins usually sit.

Inventory what runs on every internet facing host

Know the runtime, framework and plugin versions on each public server, and rebuild fast when they change. Loxone held its website relaunch until it had installed patches for the two critical PHP flaws disclosed on 20 October. That is the right instinct, and it depends on knowing which servers run PHP and in which version. Our posts on PHP2Shell and on finding and patching every PHP runtime cover that in detail. No source connects the Loxone intrusion, detected on 18 October, to those PHP flaws, and this post does not suggest a link.

Minimise and age out partner and applicant data

Support requests do not need to live forever in a CRM. Applicant data has a natural end of life once a hiring decision is made. Heise reports Loxone saying that some of the material the attackers showed was outdated. Retention limits shrink what a future breach can take, and data protection law already expects them.

Make credentials in support tickets impossible, not just discouraged

Ask for remote access through a time limited, auditable channel instead of a password in an email. Strip or mask strings that look like credentials on ingest. Close the loop with partners: if a credential arrives anyway, reply asking them to rotate it.

Prepare the partner phishing message before you need it

Loxone was able to phone relevant partners, email partners and publish named lookalike domains within days. Having that message drafted in advance (what we will never ask for, how to verify us, our bank details have not changed) is cheap and makes the first 48 hours far calmer.

Protect the update channel above everything

For any vendor whose software runs in buildings, vehicles or factories, the update infrastructure and the signing keys are the crown jewels. Loxone's statement that update infrastructure and development systems were unaffected, plus rebuilding the build pipeline as a precaution, is exactly what customers needed to hear. Segment build and signing from corporate IT, and keep signing keys in hardware.

Track vendors as part of your own risk register

If you are a building owner, facilities team or integrator, Loxone is one of your vendors. Record it in your vendor register with what data it holds about you, what notice you received and what you changed in response. Our post on third party risk lessons from the IDCF Cloud ransomware incident walks through that discipline.

Open questions

• Attack path. Loxone has identified and closed it but will not publish it. The ORF interview points to a web server. The vulnerability or misconfiguration is not known publicly.
• Volume and contents. The 201.6 GB claim is the attackers'. Loxone has not confirmed a volume or a record count.
• The serial number list. heise describes a posted list of 300,000 Miniserver serials with project names. Loxone has not confirmed it and says some shown data is outdated. Whether such a list exists, how old it is and where it came from are open.
• Microsoft 365 and SSO details. Mentioned in the posted samples per heise; not addressed in Loxone's statements that we read.
• Ransom. Loxone declined to say whether a ransom was demanded. Whether the group published anything after its stated deadline of 22 October is not covered by any source we fetched.
• Number of people affected. Not yet published for partners or applicants.
• Attribution. Only the self chosen name "Samurai" is known. No source links it to a known group, and this post does not.

What would have helped

Practices any team can use

The vendor practices above, in short: segment public web servers from CRM and HR data, keep a live runtime inventory of every internet facing host, use least privilege service accounts with rotation, alert on bulk exports, set retention limits, keep credentials out of support channels, prepare the partner message in advance and keep the update and signing path separate. For installers: one user per person, least rights, time limited service accounts, Remote Connect or a VPN instead of port forwarding, and a call back on a known number before acting on any request.

Where Safeguard fits

The honest answer is that Safeguard's fit with this incident is indirect. Safeguard does not filter email, does not detect phishing, does not manage Miniservers or building automation, and does not monitor a CRM for bulk exports. It would not have stopped this intrusion, and it plays no part in the installer steps above.

Where it does help is in the software around incidents like this:

• Knowing what your public web servers are built from. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, results as JSON under ./output). Its software composition analysis covers ecosystems including Composer and npm, which are common in web shops and portals, plus container layers. When a runtime flaw lands, the platform shows which projects contain a given component and version, so the patch list is ready.
• Ranking what matters. Vulnerability matching draws on public vulnerability databases including CISA KEV, and reachability analysis ranks the flaws your code actually calls.
• Keeping fixed versions fixed. Policies and gates evaluated in the platform can block a build that reintroduces a known vulnerable version.
• Tracking vendors and controls. The Compliance and GRC suite includes Vendors, Risks, Controls and Evidence tabs, so a building owner or integrator can record a vendor incident like this one, the data that vendor holds and the actions taken.
• Keeping a person on every action. The Safeguard CLI's assistant asks before it edits files or runs commands in its default modes (/permissions offers Ask, Accept edits, Plan, Auto and Strict). The desktop and phone apps send work to a computer running the CLI, where each command is approved or denied. That is the same principle this incident teaches installers: a request is not an approval.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh) is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses.

None of these relate to the Loxone intrusion. There is no CVE for it, and the vulnerable component, if there was one, has not been named. They matter for the web stack every vendor runs in front of its CRM: pull patched, signed components from a curated source and rebuild quickly when the next runtime flaw lands.

Common mistakes

• Assuming the Miniserver is compromised and resetting everything at once. Loxone says installations are unaffected. A panicked factory reset of many sites creates more risk (default credential windows, rushed passwords) than it removes. Work through the checklist calmly instead.
• Believing a message because it knows real details. The stolen data is exactly what makes a phishing email accurate. Accuracy is not proof of origin.
• Calling the number in the email. Always call a number you already had before the message arrived.
• Leaving the shared admin account in daily use. One shared password across technicians is the hardest thing to rotate after a breach.
• Pasting credentials into a support form "just this once". Loxone's advice is never to do it.
• Treating attacker claims as facts. A ransom note is a sales pitch. The 201.6 GB figure and the serial list are claims until Loxone or an independent analysis confirms them.
• Reading the PHP patch note as the cause. Loxone patched PHP after the intrusion because new flaws were disclosed on 20 October. No source links the two.

FAQ

What happened in the Loxone cyberattack?

On 18 October 2026, Loxone detected an attack on internal company systems. Data was copied, mainly from its CRM and applicant management. Loxone isolated systems, worked with external forensic experts, informed authorities and restored services in stages between 19 and 23 October.

What data was taken?

Per Loxone, data copied may include business partner contact details (mainly electrical installation companies, according to heise), support requests and applicant data. The full scope is still being reviewed.

Are Loxone Miniservers or my building at risk?

Loxone says no. Miniservers run locally with their own credentials, Loxone holds no central database of installation logins, and Remote Connect and Exosphere were not affected. Loxone says there have been no security incident reports from customer installations since the attack.

Is it safe to update my Miniserver?

Loxone says yes. Its update infrastructure and development systems were not affected, the codebase was confirmed not compromised, the build pipeline was rebuilt as a precaution, and software bearing the Loxone signature is genuine.

Who are "Samurai" and did they really take 201.6 GB?

"Samurai" is the name the group used in the ransom message on loxone.com. The 201.6 GB figure comes from that message. Loxone has not confirmed the volume, and no source links the name to a known group.

Did the attackers get 300,000 Miniserver serial numbers?

heise describes a list posted by the attackers that includes a register of 300,000 serial numbers and project names. Loxone has not confirmed it. Serial numbers are not secrets in Loxone's design; they appear in every Remote Connect address. Access still needs a user and password held only on the Miniserver.

How did the attackers get in?

Loxone has identified the attack path but will not publish it. President Florian Wöss told ORF that it came through one of the company's web servers, according to several outlets citing the interview.

I am a Loxone installer. What should I do first?

Verify any unexpected request through a known phone number, flag @loxon.com and @luxone.com in your mail system, change any credentials you ever sent in a support request, and move every site to individual, least privilege user accounts.

I applied for a job at Loxone. What now?

Wait for Loxone's direct notice, be careful with unsolicited messages about your application, and change any reused passwords. You can ask Loxone what personal data it holds about you.

Did the PHP2Shell flaws cause this breach?

No source says so. The intrusion was detected on 18 October; the PHP flaws were disclosed on 20 October. Loxone delayed its website relaunch until PHP patches were installed, which is a separate precaution.

Fix it without waiting for upstream

The Loxone intrusion has no public CVE and no named component, so there is nothing here to upgrade. The block below is about the web stack every vendor runs in front of its customer and partner data, where the next runtime flaw will need a fast, tested fix.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Loxone, a Miniserver or this intrusion. Each shows a real Safeguard flow that applies to the web stack a vendor runs in front of its partner data, or to the principle installers now need: verify, then approve.

The first demo is a real CLI session. You install the CLI, open the interactive terminal and ask it to fix the lodash CVE in a repository; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. For a vendor patching a partner portal after a runtime flaw, you would run the same scan against the portal's repository or image and ask for the dependency bump, approving each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the runner on your own machine, approves it with its device code and then scans from the terminal. For a team that wants to inventory every internet facing web project quickly, this is how scans run on your own hardware without sending code elsewhere.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. It is the same habit this incident asks of installers. A request arrives; you read exactly what it is; you approve it on a device you hold, or you refuse.

Click through it at your own pace, or open it full screen.

To try Safeguard on your own repositories, download Safeguard and follow the CLI docs. For the wider picture of this month's incidents, see October 2026 security incidents and what would have helped.

Quick check

Sources

• Loxone: Cyberattack on LOXONE, incident updates and FAQ (security.loxone.com, German)
• Loxone: international homepage notice on the cyberattack, 19 October 2026 and later
• Loxone: press release, 19 October 2026 (German PDF; served the homepage notice when we fetched it)
• Loxone: press notification, 19 October 2026 (English PDF; served the homepage notice when we fetched it)
• Loxone Knowledge Base: Remote Connect
• Loxone Knowledge Base: External Access
• Loxone Knowledge Base: Port Forwarding
• Loxone Knowledge Base: User and Rights Management
• Loxone blog: Security improvements to Loxone Cloud DNS (2020)
• heise online: Loxone cyberattack hits building automation provider (19 October 2026)
• cyberattaque.org: Cyberattaque contre Loxone (19 October 2026)
• QUASA: Loxone attack hit CRM and applicant data, scope still open (22 October 2026, German)
• Dysruption Hub: Loxone cyberattack disrupts orders, Pennsylvania entity (20 October 2026)

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.