Hollys Breach: Cryptomining Intrusion Exposed 2.76M Old Member Records

Korean coffee chain Hollys says an outsider who abused a cloud service to mine cryptocurrency also took a temporary data file from an old membership overhaul, about 2.76 million records of members who joined between 2009 and 11 February 2020. IDs, passwords, names, birth dates, phones, addresses and emails are in scope. Change reused passwords now.

The unusual part of this story is not the size. It is the shape. By the company's own account, the attacker came for compute, not for customer data, and the customer data that left was not the live membership database but a working copy made for a past project. That copy, holding more than a decade of sign ups, was still sitting in a place an intruder could reach in September 2026.

This post sets out what Hollys and the Korean press have confirmed, where the reporting disagrees (most visibly on when the intrusion was detected), what the nine leaked data items mean for members and for anyone who runs a login system in Korea, and what any team running workloads in the cloud can check this week. Hollys has not said which cloud provider was involved or how the intruder got in, and we do not guess. Where this post describes how cryptomining intrusions usually work, it says so and cites public frameworks rather than this incident.

What happened

Hollys operates about 530 outlets in South Korea and is owned by KG Group, according to the Korea Times. Its operator, formerly Hollys F&B, became KG Hollys F&B after KG Group bought a 93.8% stake in September 2020 and was renamed KG F&B in 2024, according to Yonhap reporting carried by the Korean Center and SBS.

On 16 October 2026 the company confirmed that an outside party had gained unauthorized access to its membership system and that customer personal information had leaked. It posted an apology notice on its website the same evening. Members received text messages on 18 October. On 19 October Hollys issued a fuller statement explaining the cause as it understood it, and gave a count: about 2.76 million records reported to the Korea Internet and Security Agency (KISA).

In that statement, carried verbatim by SBS Biz, Yonhap and Seoul Shinmun, Hollys said its understanding was that an external attacker accessed a cloud service abnormally in order to mine cryptocurrency, and that part of the customer information leaked in the process. It said the leaked data was a temporary data file provided for a past membership service overhaul, not the currently active customer database, and that it estimates the file holds cumulative customer data from 2009 to 11 February 2020, duplicate members included. It said the exact scale is still being checked.

Timeline

The bodies of the two leak notices did not render in our fetches of the Hollys notice board, so the timestamps and titles above come from the board itself and the content comes from the company statements as published by the Korean press. The 7 October server migration notice is a separate, routine looking announcement. No source links it to the incident, and neither do we.

The detection date discrepancy

Reporting disagrees on when Hollys found out.

• The Korea Times, publishing Yonhap's English copy on 19 October, says the data was stolen between 3 September and 7 October, and that Hollys "detected unauthorized access to its system on Oct. 7."
• The Korean language statements and texts, as reported by SBS Biz, Yonhap (via the Korean Center), Seoul Shinmun, Kyunghyang, News Tomato and Economist Korea, say Hollys confirmed the unauthorized access and the leak on 16 October, and that the leak itself is estimated to have happened between 3 September and 7 October. MoneyToday's English edition and SBS's English site also give 16 October.

The most likely reading is that 7 October marks the end of the estimated leak window rather than the day of detection, and that the English summary compressed the two. We cannot rule out that some anomaly was noticed earlier, because Hollys has not published a detailed internal timeline. This post uses "confirmed 16 October, leak window ending 7 October" throughout. The gap matters for one reason: under Korea's Personal Information Protection Act, the clock for notifying people and reporting to regulators runs from when a company becomes aware of a leak, so the date of awareness is the date regulators will ask about.

What leaked and who is affected

Hollys listed nine categories of data. The table sets them out with what each one means in practice.

Who is affected, per the company and the texts it sent:

Two cautions on the numbers. First, 2.76 million is the count Hollys reported to KISA, it includes duplicates, and the company says the exact scale is still being confirmed. It is a count of records, not of people. Second, MLex rounds the figure to 2.8 million. Neither number has been independently verified, and we use the company's figure with that qualifier.

Why a cryptomining intrusion turned into a data breach

Most cryptomining intrusions in the cloud end with a large bill and a cleanup. The attacker wants CPU or GPU time, starts as many miners as the stolen access allows, and moves on when the instances are terminated. That is why many teams file "cryptojacking" under cost incidents rather than data incidents.

This case shows the weakness in that habit. The company says the attacker's purpose was mining. Whatever access the attacker used to start mining was also enough to reach a stored file of customer data. Access that can start compute in a cloud account often can also list and read storage in that account, because the same credentials, roles or service accounts tend to carry both rights. Once an outsider holds those rights, their stated motive does not limit what they can do with them.

MITRE ATT&CK describes the technique as Resource Hijacking (T1496), with Compute Hijacking (T1496.001) covering the use of co opted systems to mine cryptocurrency. MITRE notes that servers and cloud systems are common targets because of the resources they offer, and that the technique "cannot be easily mitigated with preventive controls" because it abuses ordinary system features. Its detection strategy focuses on persistent high CPU use combined with unusual processes and outbound connections to mining or proxy networks.

Typical ways in (general patterns, not this incident)

Hollys has not disclosed its cloud provider or the initial access path. The patterns below are the common routes into cloud accounts for mining, drawn from the public frameworks and cloud provider guidance cited in this post. They are not a description of what happened at Hollys.

1. Long lived access keys that leak. Keys committed to a repository, baked into a container image, left in a CI log or stored on a developer laptop. AWS's own guidance says to use temporary credentials such as IAM roles "instead of creating long-term credentials like access keys."
2. Exposed management interfaces. Container orchestration APIs, dashboards or remote admin ports reachable from the internet without strong authentication.
3. Vulnerable internet facing applications that let an attacker run code on a host, then read the instance's metadata credentials.
4. Dormant service accounts and keys from finished projects that nobody owns any more. Google Cloud's Security Command Center lists "Initial Access: Dormant Service Account Action" among the early warning findings that often come before a miner appears.
5. Stolen or reused console passwords for accounts without multi factor authentication.

The common thread is identity. In the cloud, the credential is the perimeter, and an old project usually leaves both a credential and a copy of data behind.

Why a migration file is the perfect thing to forget

Data migration projects create copies by design. A team exports the membership table, often in full and in plain formats such as CSV or a database dump, so a vendor or a new system can map fields, test imports and verify counts. Hollys described the leaked file as one provided for a past membership service overhaul. Copies like these share a few traits that make them easy to lose track of:

• They sit outside the production database, so they miss the database's access controls, encryption settings, audit logging and retention jobs.
• They are owned by a project, not a system. When the project closes, nobody is left whose job is to delete them.
• They are often complete. A full export includes withdrawn members, test accounts and fields the new system never needed.
• They are frozen at a point in time. The Hollys file stops at 11 February 2020, which suggests it was produced around then and outlived its project by years.

Nothing here is a judgement about what Hollys did or did not do. It is the reason any organisation that has run a migration, a data warehouse load, an analytics pilot or a vendor onboarding should go looking for its own copies this week.

Technical details

Hollys has not published indicators of compromise, the name of the cloud service, the type of storage that held the file, the file format, or how passwords were stored. There is no CVE, no affected software version and no malware hash in any primary source we could find. The details below are what has been disclosed, plus the specific, documented detection identifiers that cloud providers publish for cryptomining activity.

Disclosed facts about the incident

DI versus CI: what the leaked identifier can and cannot do

Korean sites that verify identity through a mobile carrier or other identity verification service receive two kinds of identifier. KISA's guide to identity verification services for online service providers defines them this way:

• CI (연계정보, Connecting Information) is one value per person nationwide, used to recognise the same person across different organisations, mainly for partner services between two or more institutions.
• DI (중복가입확인정보, Duplication Information) is one value per person for one website, used to recognise the same person within the site that adopted the verification service, for example in ID or password recovery.

Hollys listed DI, not CI. That matters. A leaked DI is a stable identifier for the person on the Hollys site, and it can link records about that person inside Hollys systems, but by KISA's definition it is not the cross service key that CI is. Some early commentary treated DI as a universal identifier. Based on KISA's definitions, that overstates it. Any site that uses DI in its own account recovery flow should still treat a leaked DI as a known value, not a secret, and should not let it alone authorise a password reset.

Cloud provider detection identifiers for cryptomining

None of these have been tied to this incident. They are the documented identifiers that let a team check its own accounts for the same kind of activity.

Amazon Web Services, GuardDuty EC2 finding types (from the GuardDuty user guide):

The guide adds that for unexpected activity, the best practice is to assume the instance is compromised and follow the provider's procedure for remediating a potentially compromised instance.

Google Cloud, Security Command Center finding categories (from the cryptomining detection best practices page). Early stage, often before a miner runs:

• Account_Has_Leaked_Credentials
• Evasion: Access from Anonymizing Proxy
• Initial Access: Dormant Service Account Action

Miner running:

• Execution: Cryptomining YARA Rule
• Execution: Cryptomining Hash Match
• Execution: Combined Detection
• Malware: Bad IP
• Malware: Bad Domain

The same page recommends enabling Cloud DNS logging so lookups of mining pool domains can be flagged, and routing alerts to a shared team mailbox because attacks often start on nights, weekends and holidays.

MITRE ATT&CK mapping for internal reporting:

Passwords

Hollys has not said whether passwords were stored as salted hashes, unsalted hashes or something weaker. The file covers sign ups going back to 2009, a period in which hashing practices across the industry varied widely. Members should assume the worst and change any reused password. Operators should note that NIST SP 800-63B requires stored secrets to be salted and hashed with a suitable password hashing scheme, with a salt of at least 32 bits. A working copy made for a migration should never contain more than the production system holds, and ideally holds far less.

What changed since the first reports

• 16 to 18 October. The first notice and texts gave the leak window, the cut off date and the data items, but no count and no cause. SBS's English report noted that the notice did not disclose the number of affected customers or whether the data had been misused.
• 19 October. The company added the cause (abnormal cloud access for cryptocurrency mining), the source (a temporary migration file, not the live database), the KISA count (about 2.76 million) and the data period (2009 to 11 February 2020). It also said it would promptly suspend the membership service that uses the affected cloud.
• 19 October. MLex reported regulator scrutiny.
• 20 October. SBS Biz, citing Yonhap, reported that a former member who had withdrawn said they received a leak notice, and raised the question of whether withdrawn members' data had been kept. This is a single source claim; Hollys has not addressed it in the statements we could read.
• Throughout, customers complained of difficulty reaching the customer centre, which played only automated messages, and of the website being down for a time on 18 October, according to Yonhap and Seoul Shinmun.

Open questions

• Which cloud provider and which service were involved, and how did the attacker first get access?
• Was the migration file stored in object storage, on a virtual machine disk, or in a database snapshot, and why was it reachable from the resources the attacker used?
• How were the passwords in the file stored?
• How many unique people are in the 2.76 million records once duplicates are removed?
• Does the file include members who had withdrawn, and if so, why was their data retained?
• When exactly did Hollys first notice anomalous activity: 7 October, 16 October or another date?
• Has any of the data appeared for sale or been used in phishing?
• What will the Personal Information Protection Commission conclude, and when?

What members should do now

1. Change your Hollys password once the site is available, and change the same password anywhere else you used it, as Hollys itself asks.
2. Turn on multi factor authentication on your email account first, because email is how most password resets work.
3. Treat texts and calls about Hollys with suspicion. Hollys says it does not send links by text and does not ask for passwords, financial details or payment information.
4. Watch for delivery, coupon and membership point scams that use your name, phone number and address. Those are the fields an attacker now has.
5. If you withdrew from Hollys membership and received a notice anyway, keep the message. It may matter if you later file a complaint with the Personal Information Protection Commission.

What any team running cloud workloads should check this week

Hollys's description fits a pattern any organisation can test for. The steps below use AWS, Google Cloud and Linux examples because those are the most common. Adapt the names for your own provider. Run every command with read only credentials first.

1. Look for mining activity you have already missed

AWS. List any cryptocurrency findings GuardDuty has raised, then check cost anomalies.

DET=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
aws guardduty list-findings --detector-id "$DET" \
  --finding-criteria '{"Criterion":{"type":{"Eq":["CryptoCurrency:EC2/BitcoinTool.B","CryptoCurrency:EC2/BitcoinTool.B!DNS","Impact:EC2/BitcoinDomainRequest.Reputation"]}}}'

# Daily EC2 spend for the last 60 days; look for steps you cannot explain
aws ce get-cost-and-usage \
  --time-period Start=2026-08-25,End=2026-10-24 \
  --granularity DAILY --metrics UnblendedCost \
  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Compute Cloud - Compute"]}}'

Then check every region for instance types you do not normally use, since miners favour large CPU and GPU instances in regions a team rarely looks at.

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws ec2 describe-instances --region "$r" \
    --query 'Reservations[].Instances[].[InstanceId,InstanceType,LaunchTime,State.Name]' \
    --output text | sed "s/^/$r\t/"
done

Google Cloud. Query Security Command Center for the cryptomining categories.

gcloud scc findings list organizations/ORG_ID \
  --filter='category="Execution: Cryptomining Hash Match" OR category="Execution: Cryptomining YARA Rule" OR category="Initial Access: Dormant Service Account Action"'

On a Linux host or container node. Look for sustained CPU use, unfamiliar processes and persistence.

ps -eo pid,user,pcpu,etime,comm --sort=-pcpu | head -15
ss -tnp state established | head -40
crontab -l; ls -la /etc/cron.* /var/spool/cron 2>/dev/null
systemctl list-units --type=service --state=running --no-pager
kubectl top pods -A --sort-by=cpu | head -20   # if you run Kubernetes

2. Inventory the credentials that can start compute

Mining needs the right to launch or reuse compute. Find every identity that has it and every long lived key.

aws iam generate-credential-report && sleep 5
aws iam get-credential-report --query Content --output text | base64 --decode > cred.csv
# Columns include access_key_1_last_rotated and access_key_1_last_used_date
for u in $(aws iam list-users --query 'Users[].UserName' --output text); do
  aws iam list-access-keys --user-name "$u" \
    --query 'AccessKeyMetadata[].[UserName,AccessKeyId,Status,CreateDate]' --output text
done

Disable keys that have not been used in 90 days, move workloads to roles with temporary credentials, and require multi factor authentication for every human console user. On Google Cloud, list user managed service account keys and look for ones created for old projects.

for sa in $(gcloud iam service-accounts list --format='value(email)'); do
  gcloud iam service-accounts keys list --iam-account "$sa" --managed-by=user \
    --format="table(name.basename(),validAfterTime,validBeforeTime)"
done

3. Check what those same identities can read

This is the step the Hollys case argues for. For each identity that can launch compute, ask whether it can also read storage that holds personal data. On AWS, the IAM policy simulator answers this without touching data.

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME \
  --action-names ec2:RunInstances s3:ListBucket s3:GetObject \
  --resource-arns "*"

If a role used by an application server can both run instances and read an exports bucket, split it. Compute roles should not read customer data unless the workload needs that data, and then only the prefix it needs.

4. Find the forgotten copies

Search object storage for files whose names suggest exports, dumps, backups or migrations, and sort by age.

for b in $(aws s3api list-buckets --query 'Buckets[].Name' --output text); do
  aws s3 ls "s3://$b" --recursive 2>/dev/null \
    | grep -iE 'member|customer|user|export|dump|backup|migrat|temp|tmp|\.sql|\.csv|\.bak' \
    | sed "s|^|$b |"
done | sort -k2,2 | head -100

gcloud storage ls --recursive 'gs://*/**' 2>/dev/null \
  | grep -iE 'member|customer|export|dump|backup|migrat|\.sql|\.csv'

On servers and shared volumes, find large, old data files.

find / -xdev -type f \( -name '*.csv' -o -name '*.sql' -o -name '*.dump' -o -name '*.bak' \) \
  -size +50M -mtime +365 -printf '%TY-%Tm-%Td %s %p\n' 2>/dev/null | sort | head -50

To confirm whether a candidate file holds Korean personal data without opening it in an editor, count lines that match a mobile number pattern.

grep -cE '01[016789]-?[0-9]{3,4}-?[0-9]{4}' candidate.csv

Also list database snapshots and disk snapshots older than a year. Snapshots are migration copies too.

aws rds describe-db-snapshots --query 'DBSnapshots[].[DBSnapshotIdentifier,SnapshotCreateTime]' --output text | sort -k2
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[].[SnapshotId,StartTime,Description]' --output text | sort -k2

5. Decide, delete and record

For every copy you find, name an owner, decide whether a current purpose exists, and if not, delete it and record the deletion. Korea's Personal Information Protection Act has a dedicated article on destruction of personal information (Article 21), and its enforcement decree sets out destruction methods. A deletion record is the evidence that the duty was met.

6. Turn on the alerts that would catch the next one

• Enable your provider's threat detection service in every region and every project, including ones you do not use.
• Enable DNS query logging so lookups of mining pool domains are visible.
• Set a billing anomaly alert with a low threshold. A miner shows up on the bill before it shows up anywhere else.
• Send alerts to a shared mailbox or on call rotation, not a single person.
• Alert on any API activity from service accounts that have been dormant for 30 days or more.

The Korean regulatory frame

Several rules shape what happens next for any company in a case like this. We summarise them from the sources we could fetch; consult counsel for specifics.

• Notification and reporting. Under Article 34 of the Personal Information Protection Act, a controller must notify affected people without delay after becoming aware of a leak. According to a January 2026 summary by a Korean law firm, Article 40 of the enforcement decree requires a written report within 72 hours of awareness when at least 1,000 people are affected, when sensitive or unique identifying information is involved, or when the leak results from external unauthorized access such as hacking. Hollys says it reported the leak to KISA and to the relevant agencies.
• Destruction. Article 21 requires personal information to be destroyed once it is no longer needed, which is why retention of withdrawn members' data is the question regulators and reporters are asking.
• Penalties. The same law firm summary describes the Article 64-2 penalty surcharge cap as 3% of total sales, excluding unrelated sales. Economist Korea reports that sanctions were strengthened this year, with surcharges of up to 10% of total revenue possible for large leaks caused by intent or gross negligence. We could not confirm the 2026 amendment text directly.
• Context. Economist Korea, citing the Personal Information Protection Commission, reports 447 leak reports last year, up about 45.6% from 307 the year before, with hacking the largest single cause at 62%. The Korea Times reports that financial regulators presume about 100,000 cases of personal information leakage across 16 financial institutions in a recent run of attacks.

What would have helped

The cause is not fully public, so none of this is a judgement about Hollys. Its statements show several things that help members: a clear list of data items, a stated cut off date, a plain request to change reused passwords, and a warning about follow on phishing. What follows is what any team that holds customer data in the cloud can put in place so that an intrusion for compute does not become a breach of data.

Practices any team can use

• Treat project data copies as production data. Any export made for a migration, a vendor or a test inherits the classification of its source. Store it with the same encryption, access control and logging, or do not make it.
• Give every copy an expiry date at creation. Object lifecycle rules that delete a migration prefix after 30 or 90 days are cheap and reliable. A human memory to clean up later is neither.
• Minimise before you export. A field mapping exercise rarely needs real passwords, real phone numbers or withdrawn members. Use masked or synthetic data, or export only the columns and rows the project needs.
• Delete on withdrawal, and test that deletion reaches copies. Retention jobs that run on the live database do not touch a CSV on a storage bucket.
• Separate compute rights from data rights. The identities that can launch instances should not be the identities that can read customer exports.
• Retire long lived keys. Move workloads to roles and short lived tokens, and alert on any use of a key that has been idle.
• Treat cryptomining alerts as possible data incidents. When a miner is found, check what the compromised identity could read, review storage access logs for the same period, and decide on breach handling from evidence, not from the attacker's apparent motive.
• Know your components. Many cloud intrusions start with a known vulnerability in an internet facing application or base image. An SBOM for every service and image means that when an advisory lands, you can find affected services and rebuild them the same day.

Zero-Day Discovery and Gold

Two Safeguard capabilities touch the component part of that last point, with clear limits.

Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. It runs in two modes, an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. It does not audit cloud identity and access settings, find stray data files or detect a miner on a host, and no package flaw has been linked to this incident.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers 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 at registry.safeguard.sh is a paid service with hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses. There is no CVE for this incident to look up in Gold.

The habit both support is simple: pull patched, signed components from a curated source, and rebuild and redeploy quickly when a fix lands. That shrinks the window in which a known bug in an internet facing service can be used as a way into a cloud account, whatever the route in this particular case turns out to be.

Where Safeguard fits

Safeguard helps with the software side of a cloud estate:

• SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image membership-api:latest, safeguard scan --sbom sbom.json, with JSON results under ./output), plus a platform view of which projects contain a given component and version.
• Vulnerability matching against vulnerability databases, with reachability analysis to show which findings sit on code paths you use.
• Policies and gates evaluated in the platform, and autonomous remediation that opens fix PRs (off by default).
• The Safeguard CLI's assistant, which edits code and runs commands with your approval under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict; safeguard exec runs it in CI. You could ask it to add an object lifecycle rule for a migration prefix to your infrastructure code, or to replace a hard coded key with a role reference, and approve each edit. Desktop and phone apps can send work to a computer running the CLI and approve each command.

Where it does not help: Safeguard does not detect cryptomining, monitor cloud bills, audit cloud IAM permissions, discover personal data in storage buckets or delete stale files for you. It does not file reports with KISA or the Personal Information Protection Commission. Because the cause of this incident has not been disclosed, we cannot say whether any of the above would have changed the outcome, and we do not claim it would have prevented it.

Common mistakes and troubleshooting

• Closing a cryptomining ticket once the instances are gone. Terminating miners stops the bill. It does not tell you what else the stolen identity did. Pull storage access logs for the whole period the identity was active.
• Searching only the regions you use. Miners are often launched in regions a team never opens. Loop over every region, as in the command above.
• Assuming a temporary file is temporary. Check creation dates. If a "tmp" prefix holds objects from 2020, the name is not a control.
• Deleting before preserving evidence. If you find a suspicious copy during an active incident, snapshot access logs and object metadata before deleting it. Then delete it.
• Trusting the attacker's motive. "They only wanted compute" is a hypothesis, not a finding. The Hollys case shows why.
• Rotating the obvious key and missing the rest. Attackers who obtain one key often create another or attach a new policy. Review every identity created or changed during the window.
• Treating DI as a secret. After a leak, DI is a known value. Do not let it alone authorise account recovery.
• Forgetting snapshots and backups. Database snapshots and disk images are full copies of customer data with their own permissions.
• Messaging customers only on the website. Several reports note that customers learned of the leak days after the website notice. Plan direct notification channels and a staffed contact line before you need them.

FAQ

What happened at Hollys?

Hollys says an outside attacker accessed a cloud service abnormally to mine cryptocurrency and, in the process, took part of its customer information. The data came from a temporary file made for a past membership overhaul, covering sign ups from 2009 to 11 February 2020. About 2.76 million records were reported to KISA.

When was the breach detected?

Korean language reports of the company's statements say Hollys confirmed the leak on 16 October 2026 and estimates the leak took place between 3 September and 7 October. The Korea Times's English report says Hollys detected the access on 7 October. The most likely explanation is that 7 October is the end of the leak window, but Hollys has not published a detailed timeline.

Does 2.76 million mean 2.76 million people?

No. The company says the figure includes duplicate members and that the exact scale is still being checked. It is a record count reported to KISA.

What data was taken?

Nine items: user ID, password, name, date of birth, phone number, address, email, DI (a duplicate sign up verification value) and service usage information.

Were passwords encrypted?

Hollys has not said. Change your Hollys password and the password on any other service where you used the same one.

I joined Hollys after February 2020. Am I affected?

According to the company, the leaked file covers members who joined before 11 February 2020. Members who joined later are not in that file. Change your password anyway if you reused it elsewhere, since phishing will target Hollys customers broadly.

I withdrew from Hollys membership years ago and still got a text. Why?

One former member told Yonhap the same thing, which raised questions about whether withdrawn members' data was kept. Hollys has not addressed this in the statements we could read. Keep the text in case you file a complaint.

Is my DI value a universal identity number?

Not according to KISA's definitions. DI is unique to one person on one website. CI is the cross organisation identifier, and Hollys did not list CI among the leaked items.

Which cloud provider was involved?

Not disclosed. Hollys has said only that it will promptly suspend the membership service that uses the affected cloud.

Would Safeguard have prevented this?

We cannot say, and we do not claim it would have. Safeguard works on software components, images and code. It does not detect mining, audit cloud permissions or find stray data files. The practices in "What would have helped" are the ones most relevant to this incident.

Fix it without waiting for upstream

The Hollys incident was not caused by a disclosed open source vulnerability, but many cloud intrusions start with one in an internet facing service or base image. The section below covers how to close that part of the gap fast.

Whatever the vulnerability, 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 Hollys or its systems. Each is a real Safeguard session, and each intro says how the same flow applies to a cloud hosted membership service.

This real CLI session fixes a lodash CVE in a sample repository: the assistant 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, and pushes nothing. For a membership API running in the cloud, you would run /scan . in its repository, ask the assistant to upgrade a vulnerable web framework in the internet facing service, and approve each command as it runs.

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

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For the cleanup in this post, you would pick your infrastructure code folder, ask for a lifecycle rule that expires objects under a migration prefix after 30 days, and approve or deny each edit yourself before it goes to review.

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

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. When an advisory lands at night for a base image your public services use, the on call engineer could approve the rebuild from a phone instead of leaving an internet facing service exposed until morning.

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

To try it on your own services, download Safeguard and follow the CLI docs. For the wider month, see October 2026 security incidents and what would have helped. For another case where a cloud provider incident became a customer problem, read the IDCF Cloud ransomware post. For fast scoping with SBOMs, see finding affected products fast, and for images, container image supply chain incidents in 2026.

Quick check

Sources

• Hollys notice board: leak notices dated 16 Oct 2026 21:36:06 and 19 Oct 2026 16:51:06 (Korean)
• Hollys: 개인정보 유출 관련 사과 및 안내, 16 Oct 2026 (Korean)
• Hollys: 개인정보 유출 관련 후속 안내, 19 Oct 2026 (Korean)
• Hollys: 서비스 일시 중단 안내 (server migration notice), 7 Oct 2026 (Korean)
• Korea Times: 2.76 mil. pieces of customers' info at Hollys leaked in cyberattack
• SBS Biz: 할리스, 개인정보 276만건 유출, 가상자산 채굴 목적 해킹 (Korean)
• SBS Biz: 할리스, 해킹에 고객정보 유출 (Korean, 18 Oct)
• SBS Biz: 탈퇴해도 안 지웠다, 할리스 고객 정보 (Korean, 20 Oct)
• SBS News English: HOLLYS Customer Addresses Compromised, Urges Immediate Password Changes
• MoneyToday: Hollys apologizes for leak of 2.76 million personal data records, including passwords
• MLex: Hollys faces South Korean privacy review over suspected breach of 2.8m records
• Seoul Shinmun: 할리스 고객 비번·주소까지, 민감 정보 276만건 (Korean)
• Yonhap via Korean Center: 할리스, 개인정보 276만건 유출 (종합3보) (Korean)
• Kyunghyang Shinmun: 할리스도 해킹에 개인정보 유출 (Korean)
• Economist Korea: 할리스, 개인정보 유출 사과 (Korean)
• News Tomato: 할리스, 고객 개인정보 유출 (Korean)
• KISA: guide to identity verification services, CI and DI definitions (Korean, PDF)
• MITRE ATT&CK: T1496 Resource Hijacking
• MITRE ATT&CK: T1496.001 Compute Hijacking
• AWS: GuardDuty EC2 finding types
• AWS: Manage access keys for IAM users
• Google Cloud: Cryptomining detection best practices
• Korea Legislation Research Institute: Personal Information Protection Act (English)
• Korea Legislation Research Institute: Enforcement Decree of the Personal Information Protection Act (English)
• D&A LLC via Mondaq: Data controllers' obligations under the PIPA in data breaches
• NIST SP 800-63B: Digital Identity Guidelines, Authentication

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