SalesDrive CRM Security Incident Letter: What an Online Store Should Do This Week

Customers of the SalesDrive CRM have received a letter about an information security incident. If your store manages orders in SalesDrive, this letter concerns two things at once: your customers’ data and the keys the CRM used to sign in to your delivery, payment and marketplace services. Below is a sequence of actions for a store owner, with no analysis of who is to blame and no assessment of the company: what exactly was put at risk, which keys to replace first, where to look for signs of abuse and what to tell customers who get calls “about your order.”

One caveat up front: we have no connection to SalesDrive as a company, and we have no additional information about the incident.

What is known from the SalesDrive letter

The only source we rely on is the letter SalesDrive sent to its customers. As of September 30, 2026, we found no public statements or news reports about the incident. So below is only what the letter says, and in the form in which the company itself presents it.

What happened

• The incident was recorded on September 7, 2026, at 02:00.
• According to the letter, “as a result of a hacker attack, a leak occurred” of information stored in the system: it refers to unauthorized access and copying.
• The first category of data is the personal data of shoppers, that is, the customers of the stores that work in the CRM: full names, phone numbers and order details, including product names, amounts and the names of the selling stores.
• The second category is system and authorization data for integrations: API keys, access tokens, authorization data for external services and marketplaces. According to the letter, this is exactly what made their “mass update and reset” necessary.

What, according to the letter, SalesDrive has done

• September 7: the source of the unauthorized access, according to the company, was identified and blocked.
• September 7–8: new servers were deployed from scratch and access keys were updated.
• Access to the servers (SSH and databases) was restricted by IP address.
• An audit of the source code and server configuration was carried out; according to the letter, the vulnerabilities found were fixed.
• All active sessions of platform users were forcibly ended.
• For its part, SalesDrive is sending a notification about the incident to the Secretariat of the Ukrainian Parliament Commissioner for Human Rights.

Integration keys: dates from the letter

According to the letter, a mass key reset was carried out together with partners:

Also, according to the letter, the API keys of SalesDrive’s applications for Gmail, Google Analytics and OLX were changed. For some partners, the company writes, work on the mass key change is still ongoing, and a separate instruction has been promised regarding SalesDrive’s own API keys.

The list of dates describes actions SalesDrive reports on its side. It does not mean that the old keys no longer work in your account, and it does not cover services that are not on the list. How to deal with this is covered below.

What the letter does not show

It is just as important to name what we do not know. The letter does not show:

• when exactly the unauthorized access began: September 7 is the date of detection, not necessarily the start;
• how many stores and shoppers were affected;
• whether it touched payment data or the passwords of CRM users;
• which partners the still-ongoing work concerns and when it will be completed;
• whether data or keys have already been abused at specific stores;
• who is behind the attack.

That is why below we draw no conclusions like “the database is already being sold” or “you are not at any risk.” Neither claim has any basis. The reasonable position is different: treat everything that was stored in the CRM as compromised and act as if someone could already be using it.

What exactly is at risk

Customer data

A name, a phone number and the contents of an order together give a fraudster everything needed for a convincing call. They know what the person bought, for how much and from which store. Typical scenarios to warn customers about:

• “Your order is delayed, an extra delivery payment is required,” with a link to a third-party payment page.
• “The item is out of stock, we will refund the money to your card,” with a request to give card details or a code from a text message.
• A messenger message on behalf of the store or the delivery service with a “track your parcel” link.

The risk of financial harm here falls on the customer, and the reputational risk falls on you: the person remembers not the CRM but the store “on behalf of” which they were called.

Integration keys and tokens

Store owners think about this risk less often, even though it is the one that leads to your money and your accounts. An API key is not the password to an account, but it gives access to whatever the key is allowed to do. A delivery service key can create waybills and see recipients. A marketplace key can change prices, stock levels or order statuses. A payment system token, depending on its permissions, can show transactions or initiate refunds. An email marketing or SMS gateway token lets someone send messages to your customers in your name.

Even if it turns out that passwords were not affected (the letter does not show this), a key that was stored in the CRM should be considered known to outsiders. This applies both to the partners on the list in the letter and to those that are not on it: a key may have been added to the settings long ago, and you may no longer remember where it came from.

Day one: an inventory of integrations and key replacement

First, the list

Open the integrations section in the CRM and write down everything connected there. Then go through your memory and your documents: what the developer connected, what managers added, what was turned on “as a trial” and forgotten. For each line, note where the key was created, who has access to that service’s account and when the key was last changed.

Do not forget the reverse direction: the key of the CRM itself, stored in the module on your website. Through it, the site sends orders to the CRM, and in some setups receives statuses and stock levels back.

Signing in to the CRM itself

The letter does not show whether the incident touched the passwords of CRM users, so start with the CRM itself. According to the letter, all active sessions have already been forcibly ended; that does not change passwords. Change the passwords of all users and turn on two-factor sign-in if it is available. Review the list of users and issued API access: remove any that are unnecessary or unfamiliar. If anyone’s CRM password matched their password for email, a payment system or a carrier account, change it there too.

Partners from the letter and those not in it

For each partner in the table above, go into your own account and check two things: the creation date of the current key or token, and that no old ones remain there. If the date is earlier than the one given in the letter, or old keys are still active, reissue them yourself.

For services that are not on the list (delivery services, including Nova Poshta, payment systems, SMS, email, telephony, the accounting system), there is nothing to wait for: reissue the keys in the order below. It is worth waiting for SalesDrive’s instruction on its own API keys, but do not postpone replacing the keys for money-related services because of it.

Order: first, whatever moves money

Changing everything within an hour is not realistic, so go from the most expensive:

1. Payment systems and acquiring: money moves through them, including refunds.
2. Delivery services, especially with cash on delivery: waybills, recipients, amounts due.
3. Marketplaces: prices, stock levels, orders, messages with customers.
4. Cash register and fiscalization, if connected to the CRM.
5. SMS, email marketing, messengers, telephony: channels that can be used to write to your customers.
6. Everything else: accounting system, warehouse, feeds, analytics.

Table: what to do with each integration

The service names in the table are examples of what is usually connected to a CRM, not a list of what was definitely stored in your account. Your list is the one you made in the first step.

How to change a key without breaking anything

A new key will not be picked up on its own: it has to be entered wherever the data exchange runs. Otherwise, after the replacement, waybills will stop being created or orders will stop coming in from the marketplace. The usual sequence is: create a new key, enter it in the CRM or module, check that the exchange works, and revoke the old one. But the old key is already compromised and remains valid until you revoke it, so keep the gap between “new one created” and “old one revoked” as short as possible: minutes, not days. For integrations that move money, it is wiser to revoke the old key immediately and accept a short pause in the exchange. Some services allow only one key: reissuing it kills the old one instantly, and the exchange will be down until you enter the new one. Do this during a quiet time and warn your managers. If the service lets you restrict a key by IP address or permissions, do it now, while you are in the settings anyway.

Before entering the new keys back into the CRM, ask SalesDrive support whether there is a separate procedure for this. After the replacement, place a test order all the way from the cart to the waybill and the receipt.

Example: the Nova Poshta API key

Let’s go through one key in detail: the principle is the same for the rest. The Nova Poshta API key is created in the carrier account, under the user account you use to work with waybills. If there is more than one key there, find out which one was in the CRM; sometimes the same key is also entered in the website module or the warehouse software. Create a new key, enter it everywhere the old one worked, and check the exchange with a test waybill; revoke the old one immediately (for other integrations, after the check), as described above. A test waybill is a real document in the carrier’s system, so delete it after the check. If you are not sure where exactly this is done in the account, ask the carrier’s support: account interfaces change, and instructions from someone else’s article can go out of date.

Checking for traces: have the keys already been used

September 7 is the date the incident was detected; the letter does not show when the access began. So, in addition to replacing the keys, review the period from September 7 to the day of replacement, and if the service’s log keeps older records, a few weeks before that as well. In the service accounts, look for:

• orders and statuses: unusual orders, mass status changes, cancellations your managers did not make;
• waybills: new waybills the warehouse did not create, changed addresses or recipients;
• money: refunds, changes to payout details, new accounts for withdrawals;
• account sign-ins: unknown devices, cities, times of day;
• users and access: new users, new API keys or connected apps you do not know about;
• messages: SMS and mailings you did not send, charges to your balance.

If you find something, do not delete the record right away. Take a screenshot with the date, save an export, write to that service’s support and only then fix it. Traces you erase yourself can never be shown later to support or to a lawyer.

Customers: what to tell them and how to protect them from fraudsters

Whether to write to everyone

The decision on whether to notify customers, and in what form, depends on your obligations as the party that collects and stores customer data, on the scope of the data and on what CRM support writes. We do not cite specific rules or deadlines here, because a legal assessment should come from a lawyer who works with personal data protection. Regardless of that lawyer’s conclusion, a short warning on your website and social media will do no harm. Write in it only what is actually true for your store. For example: “We notify you about payments and extra charges only through [your channel]. If someone writes to you or calls on our behalf in any other way, check your order on the website or call us at the number on the website.” If you send payment links yourself, say so, and say which address or number they come from.

A template for managers

Customers will start asking, and it is better for all managers to answer the same way and without promises the store cannot keep. Something like this, filling in the brackets with what is true in your case:

Thank you for reaching out. We notify you about payments and extra charges only through [your channel]. I will check the status of your order right now. If someone called or wrote to you on our behalf, please tell me the date, the number and what exactly they asked for, and we will record it. Do not give anyone your card details or codes from text messages.

What a manager should not say: “your data is safe,” “it wasn’t us,” “nothing leaked.” You cannot prove any of these statements right now.

Record every inquiry

Set up a simple spreadsheet: date, customer, order number, what happened, what number they were called or written from, what was answered. It will be useful for the lawyer, for the conversation with the CRM and for seeing whether fraudulent calls are happening at all and whether they concern your orders specifically.

What to document for yourself and your lawyer

While events are fresh, gather in one folder:

• the SalesDrive letter itself with the date you received it;
• the list of integrations and the replacement date of each key;
• traces found, with screenshots and exports;
• the spreadsheet of customer inquiries;
• correspondence with the support teams of the CRM and the services.

According to the letter, SalesDrive, for its part, is notifying the Secretariat of the Ukrainian Parliament Commissioner for Human Rights about the incident. Whether you as a store need to do anything, by what deadline and in what form is a question for a lawyer. We deliberately do not cite laws here: a wrong legal provision in an article like this is worse than none.

Can you keep working in the CRM

That decision is yours, and we will not push it in either direction. Moving to another CRM in the middle of the season is a risk of its own: lost history, retraining managers, new integrations. Questions worth asking support so you can decide calmly:

• what data from your account was in the system at the time of the incident;
• which keys, besides those named in the letter, you need to change;
• whether the key reset has been completed for the partners your store works with;
• whether you can export your data in full if needed.

The answer to the last question is useful whatever you decide: without an export, you have no plan B.

How not to depend on one place

This September brought two different events, but the lesson from them is the same: do not keep everything in one place. We wrote about the first one, a destroyed data center, in the article what a website owner should do when hosting goes down. The second is the incident this letter reports. In both cases, the damage grows with how much was kept in one place. What you can do in a calm week:

• A separate key for each integration. Not one delivery service key for the website, the CRM and the warehouse, but three. Then a compromised key is changed in one place and does not break the rest.
• Minimum permissions. If a key only needs to read orders, do not give it permission to create refunds. Where a service allows IP address restrictions, turn them on.
• Two-factor sign-in for the accounts of payment systems, delivery services, marketplaces, the domain registrar and the CRM itself.
• A key register. One page: where each key was created, where it is used, who has access, when it was changed. Do not write the key itself there, only where it is stored. When you have to change everything at once, a page like this saves hours.
• A replacement calendar. Once every few months and after every departure of a person with access.
• Less personal data in notes. Card numbers, passport details and private information in order comments are not needed for delivery, and in a leak they become part of the leak.
• Regular data exports from the CRM to your own storage, plus an understanding of how you will operate if the CRM is unavailable for a week. That is your plan B.

None of these steps removes the risk of a leak at a service you use. They do something else: a leak becomes manageable, because you know what to change and you change it in hours, not weeks.

If you are not a SalesDrive customer

The whole check above works for any CRM, ERP or accounting system where you once entered keys for delivery, payments and marketplaces. It is worth going through it without a trigger: make a list of integrations, find the keys nobody remembers and remove unnecessary permissions. The best time to do it is before any incident letter arrives.

Reviewing the list of integrations and keys is part of our work on store integrations. We name the timeline and scope after we see your list.