Knowledge Base access rights 'glitch' blamed for Acronis data leak

happygeek 2 554 Views

Acronis responds to DaniWeb questions regarding a leak of customer data which, as we exclusively reported over the weekend, resulted in some information being indexed by search engines and accessible to anyone on the Internet.

dweb-acronis2

Although the leak itself was identified by Acronis on Friday 29th June, the email informing those customers whose data was included in the spreadsheet that ended up exposed only went out late in the day on Friday 6th July. DaniWeb itself was only made aware of the problem, by one of those customers, on Saturday morning. As a result, contacting someone at Acronis for an official comment regarding the incident proved a little tricky. However, Acronis did swing into action and the relevant people were tracked down in order to provide that comment which arrived very late in the day (well, night here in the UK) on Sunday.

Here's what Ed Benack, Chief Customer Officer at Acronis Customer Central told DaniWeb about what actually happened:

"We have a strict content management policy that applies different access rights to our Knowledge Base, depending on content – for example, some may be Partner only, some may be Customer only. For reasons we are still investigating, the access control list reset to the default setting, making all content visible, temporarily. The vast majority of this content in the Knowledge Base is not sensitive or confidential, however it did contain an older spreadsheet listing just the email addresses of customers who had been entitled to a free product upgrade, and their upgrade license key. In compliance with our customer information security policies, no other identifying information was contained in this spreadsheet. The rights issues were addressed immediately, and we are still investigating why this occurred in the first place. In addition, we have updated our policy and moved all internal files to a completely separate database to further protect customer information, should another unexpected software glitch occur. This glitch did not occur in an Acronis product. We do pass our apologies on to those customers affected,and we have offered a further free product upgrade. We were pleased that our data security policies had prevented any other information from being released. Customers can be assured that we have a multi-level approach to protecting their personal information."

Dani AI

Generated

Useful, practical context and next steps for the thread raised by and the concern about response time from .

When a public-facing knowledge base accidentally exposes internal content the immediate priorities are containment, evidence preservation, and clear customer communication. Containment means removing or restricting the page (or the KB entry), clearing cached copies and search-engine snippets, and preserving server logs and timestamps for a later root-cause analysis. A formal incident-response playbook that prioritizes rapid customer notification is important because it reduces downstream risk and supports follow-up remediation. (csrc.nist.gov)

Concrete technical steps that should be taken right away include: take the item offline or replace it with a 410/404 response, use Search Console / removals tooling to clear cached snippets and temporary index entries, revoke or expire any exposed secrets or license keys and reissue replacements as needed, and enable monitoring/alerts for any suspicious use. Keep forensic copies of the exposed files and access logs before changing system state. Using the search-index removal features speeds cleanup of public search results while you work on permanent fixes. (developers.google.com)

Longer‑term mitigations to prevent recurrence focus on access control, separation of duties, and automated checks. Apply deny‑by‑default access rules; use role‑based access control and strictly enforce least‑privilege for both human and machine identities (audit privilege changes regularly); separate internal-only files from web‑facing content stores; add CI/CD checks that validate ACLs and block deploys that widen visibility; and log + alert on unexpected ACL changes so you catch a drift quickly. These are standard controls for broken/weak access control issues. (owasp.org)

Practical advice for affected customers: ask the vendor for a written incident summary (scope, root cause, keys revoked/reissued, time to detection/notification), request rotation of any credentials that were exposed, monitor for unauthorized activity, and demand a post‑incident plan with timelines for audits and remediation. Vendors should publish a short, dated post‑incident report and adopt baseline hygiene from frameworks like the CIS Controls to make these processes repeatable. (cisecurity.org)

Member Avatar for CMaker3
CMaker3 0 Newbie Poster

I'm a customer of Acronis and didn't receive an email regarding the issue. But I am concerened about the length of time it took them to respond to the "threat" and it took a customer to make them aware of the security leak.

No one is immune from security issues. It's how fast and effective a company responds to such a break that says about how good a company is in dealing with security issues. And this incident, even if not much damage was done as reported, doesn't speak well of Acronis' ability to respond efficiently.

I hope they correct this or should I start "scanning" elsewehre.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.

Edit Preview