What to do if your website is hacked or your server shows suspicious traffic

The critical PHP security fixes released in October 2026 are a reminder to check the technology beneath your website. PHP runs many websites, online shops and business systems. A flaw in that runtime can put a site at risk even when its design is new and its content management system is regularly updated.

This guide explains what has changed, how to distinguish a warning from a confirmed incident and what to ask your technical team. It also covers personal data protection duties and the use of artificial intelligence (AI) in security research and cybercrime. A large number of discovered flaws does not mean the same number of real attacks.

Facts and listed versions were checked on 31 October 2026. PHP security advisories, AI examples and GDPR guidance were checked again on 4 November 2026. Before updating, also check the latest notices from PHP and your hosting provider or operating system vendor.

Five things to do first if you suspect an incident now

The steps below will help you prepare for a discussion with specialists and follow their work. One business may need to isolate a single website. Another may also need its hosting account, email, database and connections to internal systems checked. The same solution will not suit every website.

What happened with PHP in October 2026?

On 21 October, the PHP project released fixes for the critical vulnerabilities CVE-2026-109618 and CVE-2026-109619. Under certain conditions, they allow remote code execution without signing in to a user account. This is known as RCE, short for remote code execution. An attacker can cause the server to run their code with the permissions of the compromised process.

The first flaw concerns the handling of incomplete internal state when memory runs out. In the second, state left over from a previous request can retain a reference to memory that has already been freed. Both problems are in the PHP runtime, but whether they can be exploited depends on the particular environment.

The PHP project's CVE-2026-109618 advisory and CVE-2026-109619 advisory, 21 October 2026.

The table lists the first versions containing these fixes. It is not a recommendation to keep using only those versions indefinitely. A Linux distribution maintainer may also apply a security fix to a package with an older version number. This practice is called backporting. Check the vendor's security advisory and the full package version.

The PHP warning covers web requests served through FPM, Apache mod_php and other integration methods. The highest risk is stated for mod_php, where exploitation has been demonstrated before application code runs. Using FPM alone is not enough to conclude that a website is safe.

The PHP project's security announcement of 21 October.

This is no longer just a theoretical warning

Both CVEs were added to CISA's catalogue of known exploited vulnerabilities on 26 October. In its report of 21 October, AWS described an exploitation attempt observed by MadPot on 17 October, before public disclosure. This supports the need for an urgent check. It does not prove that a particular company's server has been compromised.

Official CISA KEV data, catalogue version dated 3 November 2026, checked on 4 November 2026; AWS Threat Intelligence observation, 21 October 2026.

CERT.LV also reported automated attempts in Latvia on 21 October. At 23:00 that day, it stated that it had no reports of successful attacks at that time. That was an assessment at a specific point in time. Preventive access restrictions on some resources are not evidence that those resources were hacked.

CERT.LV's announcement about the situation in Latvia, 21 October 2026, update at 23:00.

Two further updates followed the emergency fix

On 23 October, PHP published information about a separate case, CVE-2026-115560. It concerns an unusual change of session serialiser while an application is running, with the upload progress feature enabled. The 21 October releases do not resolve this separate case. The vendor describes a temporary configuration measure until the next regular fix. This does not present the same risk to every website.

On 26 October, rebuilt Windows packages were released as 8.2.35-1, 8.3.36-1, 8.4.27-1 and 8.5.12-1. They update the Brotli library to address CVE-2026-111497. The issue can arise when an application enables automatic HTTP response decompression in cURL. The base PHP version number does not change in this rebuild.

An update is complete once the packages and configuration have been verified. A screenshot saying “PHP updated” does not show whether the fix is working in the environment concerned.

PHP announcements of 23 and 26 October; Brotli 1.2.1 release.

A “PHP problem” can mean several different things

A website is built from several layers of technology. Before security work begins, establish what runs in each layer, where it is hosted and who maintains it.

• Server and infrastructure. The operating system, web server, hosting management, network rules and libraries.
• PHP runtime and configuration. The specific version, FPM or another integration, extensions and configuration settings.
• Application. WordPress, Drupal, PrestaShop, a Laravel project or a bespoke system, including plugins, modules and Composer packages.
• Access and connections. Administrators, SSH keys, database accounts, email, CRM, payments, deployment tools and AI services.

The PrestaShop module ps_facetedsearch illustrates the distinction. Its vulnerability CVE-2026-54159 was disclosed by the vendor on 3 June, and CERT.LV issued a warning on 8 October. The affected module versions are listed as 3.0.0 to 4.0.3, with a fix included in 4.0.4. Use of the relevant price or weight slider filters also matters. Updating PHP by itself does not fix this module flaw.

PrestaShop module security advisory; CERT.LV warning.

CVE-2024-4577, meanwhile, concerns an older Windows/PHP-CGI configuration issue. It is not a new vulnerability from 2026 and cannot automatically be applied to every Linux server. Choosing the right fix requires identifying the particular problem and configuration, rather than relying on the word “PHP” in a headline.

DEVCORE's original research on CVE-2024-4577, 6 June 2024.

What does unusual traffic tell you, and what does it not prove?

Is someone sending large numbers of requests to your server, or is the server itself making unexpected connections? Start by distinguishing these situations. “Outgoing bytes” in a hosting dashboard can include ordinary responses sent to visitors. That is not the same as the server initiating a connection to an unfamiliar system.

The table gives practical examples to help guide the investigation. A single traffic chart is not enough to identify the cause of an incident.

A foreign IP address does not prove where an attacker is located. A request sender can choose their own User-Agent text. An HTTP 200 response does not prove successful code execution, and a 404 does not rule out a successful attack through another request.

A conclusion is better supported when a particular request can be linked to a new process, file changes, an unexpected connection and an unauthorised action in an account. These are separate pieces of evidence that must be assessed together. If logs were not retained, it may be impossible to establish parts of the incident with confidence. In that case, there is no basis for saying that nothing happened.

The priority in the first hour is to stop the damage

Not every incident can be resolved in 60 minutes. This section describes the initial work that needs to start in parallel. The technical team contains the damage, the business establishes the effect on customers, and a designated person records decisions.

Put one person in charge of coordination

If the owner, hosting provider, developer and marketing specialist act independently, changes become difficult to track. Agree who approves them and where completed work is recorded. Each entry needs a time, an observation, the change made, the person who made it and the result.

During the first conversation, establish which services share the same infrastructure. A single hosting account may contain the company's website, an old test project and several customer domains. If a problem began on one site, do not automatically assume the others are unaffected.

Preserve evidence without delaying containment of active damage

With your hosting provider or administrator, preserve the available logs, the state of the files and database and, where needed, a system snapshot. Store the evidence copy separately with restricted access. Do not use it to restore the public website without checking it first.

A restart can destroy information held in memory about processes and connections. Sometimes, however, a system must be shut down, for example when data is being destroyed and there is no other way to stop the damage. A specialist should choose the order of evidence collection and isolation according to the situation.

Sections 3.1 and 5.2 of NIST SP 800-86 discuss volatile evidence and decisions about shutting down a system. The reference here is to the digital forensic principles published in 2006.

Contain the affected environment

Depending on the situation, you may need to isolate the server from the network, stop the affected website or revoke specific access. Agree how the necessary administrative access will be maintained so you do not accidentally lock out the specialists restoring the system.

If customers need an update, a static notice page can be hosted in a separate environment that the attacker has not affected. Maintenance mode in the same compromised content management system (CMS) does not establish that the attacker has been stopped. Web application firewall (WAF) rules may block some attack attempts, but they do not replace a fix or an incident investigation.

NCSC technical response guidance covers containment and removal of the cause. Actions must be adapted to the particular system.

Communicate using facts you can support

An initial report should identify the domain, the signs observed, when they were noticed, the hosting provider and the actions already taken. Suspected unauthorised access that is still being investigated is not the same as a confirmed leak of customer data. Equally, you should only claim that data is unaffected when there is technical evidence to support it.

If there is reason to report an incident or coordination is needed, follow CERT.LV's reporting instructions. Some businesses may have additional reporting duties under sector rules, contracts or cybersecurity requirements. Check these alongside the GDPR assessment.

What not to do, even when you want everything fixed immediately

The site brings in revenue, customers are calling and the hosting provider is asking you to act. The urgency is understandable, but some apparently quick actions can make the situation worse.

• Do not delete everything suspicious without preserving it. A file's contents, location and timestamps may help establish how the attacker got in. Analyse it in isolation. Do not open a suspicious PHP file through a browser “to test it”.
• Do not put yesterday's backup straight into production. The attack may have started earlier. The backup may contain both malware and the same unresolved vulnerability.
• Do not treat an update or a scanner's green result as the end of the incident. Neither can, on its own, verify every account, connection and access mechanism left by an attacker.
• Do not change passwords from a suspicious device. If an attacker still controls the computer, mailbox or management environment, the new password may reach them just as quickly. Restore control of access from a trusted environment.
• Do not disable protections on a hunch. Broad file-write permissions, removed resource limits or blindly copied configuration can create the next problem. Temporary measures need a specific justification.
• Do not publish phpinfo(), configuration files or complete logs. Passwords, keys, session data and customer information must not be posted to a public forum, an unvetted “cleanup” service or an unapproved AI chat.
• Do not hide uncertainty behind an overconfident promise. If the investigation is continuing, explain what is known, what is still being checked and when the next update will be available. “Everything is fine” is not an incident report.

OWASP recommends excluding passwords, access tokens, encryption keys and other secrets from direct inclusion in logs. Access to logs and their transfer must also be protected so the investigation does not create another data leak.

OWASP Logging Cheat Sheet.

What the technical team should check

The technical team needs to establish what is running on the server, which evidence remains and how the attacker could have gained access. The scope depends on the signs observed and the system's architecture. The following checks must therefore be adapted to the website concerned. If damage is continuing, it must be contained alongside the investigation.

Check the PHP environment that actually serves the website

The PHP version shown on the command line does not, by itself, tell you which version the website uses. One server can have several PHP executables, FPM pools and containers. Identify the PHP interface, or SAPI, used to process web requests and the configuration it has loaded. As the PHP documentation explains, different runtimes can use different configuration files. Obtain this information through the server's management environment, without creating a publicly accessible diagnostics page.

Compare the installed package's full version number with the operating system or hosting vendor's security advisory. Some vendors apply a security fix to an older release without changing the base PHP version number. Red Hat also describes this practice. An older number alone therefore does not prove that a system is vulnerable. However, a promise of support is not a substitute for checking that the particular fix is installed. You need to know who maintains the package and until when.

After updating, check the running processes too. New files on disk do not mean that every PHP process serving requests is using the fixed version. Depending on the server architecture, processes may need to be replaced, a service restarted or a new container launched. Confirm that the old processes have stopped. Coordinate these actions with evidence collection and service continuity requirements.

Use logs to reconstruct the sequence of events

A web server's access log shows only part of the picture. Compare its entries with application errors, administrator activity, hosting logins and available network data. First establish the time zones and any differences between server clocks. Request identifiers, accounts and timestamps can help connect records of the same action. OWASP guidance recommends recording application security events and protecting logs. Do not include passwords, access tokens or session identifiers in diagnostic output without assessing the consequences.

For example, a connection to an external system may be needed to send an order. Establish which process made it, under which account, to which destination and whether it occurred while the order was being processed. Unexplained code changes or a new administrator discovered at the same time increase concern. But the same IP address in two logs does not, by itself, prove that the events are connected.

An administrator authorised to examine the Linux server concerned can use these commands to read its current state.

date -u
ps -eo pid,ppid,user,lstart,comm
ss -ntp

The commands show UTC time, processes and current TCP connections. Process arguments are deliberately excluded because they may contain passwords or other credentials. Permissions and container boundaries limit what is visible. The output does not reveal connections that have already ended or certify that a system is clean. If the attacker controls the server itself, its tools may also return misleading information. NIST's guidance on evidence collection explains this limitation.

Check whether the attacker has left a way back in

Examining one suspicious PHP file is not enough. Other changes in the website and connected systems may restore the attacker's access or continue harming visitors. Check several areas.

• Configuration files. Look for unexplained changes to .user.ini, .htaccess, PHP settings for automatically loaded files and web server request routing.
• Scheduled tasks. Examine new cron entries, services and application jobs whose origin and purpose are unknown.
• Accounts and the database. Look for unfamiliar administrators, altered permissions, injected JavaScript and redirects.
• The deployment process. Check the repository, deployment scripts and the automated testing and deployment system, or CI/CD. Changes here may reintroduce unsafe code in the next release.

Compare findings with a trusted software release and documented changes. An unusual file may have been created for development, while a familiar name does not make a file safe. A file's date alone does not establish its origin either. The investigation should identify which parts of the system are affected, the evidence supporting that conclusion and what remains unknown.

Verify the restored system before returning to normal operation

The recovery method depends on the extent of the incident. If the attacker's changes cannot all be established reliably, rebuilding the environment from trusted sources may be more appropriate than repairing individual files. Install verified application code and necessary components with a reviewed configuration in the new environment. Copying the entire old server directory may copy the problem too. NCSC's system recovery guidance describes this approach.

An older backup can also contain malware. The attacker may have been in the system before the first visible signs. Choose a backup using the timeline established during the investigation, and check it before use. NIST's recovery recommendations call for verifying the integrity of recovery data and addressing the causes of the incident before returning systems to normal operation.

An online shop also needs its business records reconciled. If the chosen backup is from Tuesday but orders continued arriving until Thursday, establish how to recover the missing orders and payment information safely. Recovery must not create duplicate invoices or lose customer enquiries. Carry out this check with someone who understands the company's working processes.

Separately review credentials that were, or may have been, exposed. Creating a new key is not enough if the old one still works. OWASP guidance distinguishes changing passwords and other credentials from revoking them. From a trusted device and management environment, coordinate the replacement of affected hosting, cloud, database, CI/CD and API credentials and revoke the old ones.

Check active administrator sessions and access granted to others too. A password change does not automatically end these in every system. OWASP's session management guidance explains that terminating sessions is a separate action. New passwords and keys must not be exposed in an environment where the attacker can still read them. Do not postpone necessary revocation until the entire investigation is finished. Coordinate changes with the people responsible for connected systems, test the new connection and confirm that the old access no longer works.

Before making the website public again, test more than the home page. Check enquiry forms, account logins, orders, email and connections to business systems. Run tests in a way that avoids charging real payments or sending unwanted messages to customers. After launch, examine errors, processes and connections against expected behaviour. NIST also recommends verifying recovery outcomes and continuing to monitor system activity.

At the end of the work, record the findings, components updated or rebuilt, access revoked and tests performed. State what needs continued monitoring. The business can use this information to decide whether to resume operation. Verification cannot remove every possible risk, but it should support the decision to use the system again.

What your business needs to know about data leaks and GDPR

While the technical team contains the attack, the business must establish whether personal data is affected. It may be held in customer accounts, orders, enquiry forms or employee documents. The General Data Protection Regulation (GDPR) also covers situations where data has been deleted, altered without permission or accessed without authorisation. It is therefore not enough to ask only whether someone downloaded the database.

Notifying the authority and informing affected people have different thresholds

A controller must notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it. The exception is where the breach is unlikely to result in a risk to people's rights and freedoms. If notification is late, the delay must be explained.

Affected individuals must be informed without undue delay where the breach is likely to result in a high risk. Assess this risk separately. The regulation provides exceptions where specified conditions are met, for example where the affected data is effectively protected. Document all personal data breaches, including those that do not require notification. If a hosting provider or another supplier acts as a processor, it must inform the controller without undue delay after becoming aware of a breach. The processor does not automatically receive an additional 72 hours.

Being hacked does not automatically result in a fine. The supervisory authority assesses the circumstances, the infringement and the company's response.

These rules are set out in GDPR Articles 4, 33, 34 and 83.

When the 72-hour period begins

Unusual traffic is a reason to investigate immediately. The period begins when the controller has a reasonable degree of certainty that an incident has affected personal data. A short initial investigation is permissible, but you must not wait for a complete forensic report. If the breach is already known but the number of affected records is still being established, provide the available information in the required notification. Add further information in phases without further undue delay.

Record when the warning arrived, what you checked and when it became clear that personal data was affected. Keep the reasoning behind a decision that notification is unnecessary as well.

Encryption or pseudonymisation does not automatically remove notification duties. Check whether the attacker really was unable to read the data, whether keys were exposed and whether the data remained available for use. Pseudonymised data may still be linked to an individual using additional information. Loss of availability of personal data can be a breach even when transfer outside the system has not been established.

These principles are explained in EDPB Guidelines 9/2022, version 2.

Three situations that can lead to different decisions

The following scenarios are fictional, not CreateIT client cases. They illustrate why a notification decision cannot be based on a single technical sign.

In a small company's record-keeping system, an attacker accessed only securely encrypted data, and the keys were unaffected. Operations were quickly restored from a separate backup, with no significant consequences for individuals. A properly supported investigation may conclude that risk is unlikely and notification is not required. The incident must still be documented.

On a recruitment website, an unfamiliar PHP file allowed access to job applications and deletion of activity traces. The investigation cannot be closed simply because the logs do not show data leaving the system. The extent of the applicants' data and its potential misuse may create a high risk, requiring both the authority and the individuals to be informed.

In a clinic's system, ransomware makes patient information unavailable and delays care. This can create a high risk even without data theft. A backup alone is not enough if the required information cannot be restored in time.

These examples draw on the ransomware and website compromise cases in EDPB Guidelines 01/2021.

DVI and CERT.LV have different responsibilities

If Latvia's Data State Inspectorate, DVI, is the competent supervisory authority, use its current notification procedure. Prepare a description of the breach, the categories of affected data and people, approximate numbers, contact details, likely consequences and measures taken or planned. If some information is not yet known, say that it is being established. A business operating across several countries must separately determine the competent authority.

On 4 November 2026, DVI's website still displayed a notice that its online form was temporarily unavailable. The authority asks organisations to complete an Excel form, sign it with a secure electronic signature and submit it using the method specified in the notice. Check the latest instructions on DVI's website before submitting. The online form being unavailable does not remove the duty to notify.

The submission procedure is described in DVI's instructions and its 26 October notice about the online form's temporary unavailability.

CERT.LV can provide technical support in responding to a cyber incident. A report to CERT.LV does not replace a required notification to DVI. Certain organisations also have separate duties to report cybersecurity incidents. These do not automatically apply to every website owner. CERT.LV also accepts voluntary reports and asks organisations to preserve evidence needed for investigation before restoring operations.

Help and reporting procedures are described in CERT.LV's incident response instructions.

CreateIT helps establish which systems and data are affected, preserve technical evidence and assemble the facts needed for a notification. Your data protection specialist or legal adviser carries out the legal assessment. This work starts alongside website recovery so decisions can be made using verified information.

How AI is used in security research and cybercrime

AI can help read code faster, identify possible flaws, organise large amounts of information and test more possibilities. Security specialists and attackers can both use it. A suspicious piece of code, however, does not by itself establish that a company's system can be attacked through it.

Four terms that must not be confused

Finding

An indication that code may contain a problem. It may be incorrect, duplicate a known finding or concern a situation that cannot occur in the system being examined.

Confirmed vulnerability

A verified security weakness with defined preconditions. Its actual impact in the particular environment still needs to be assessed.

Exploit

A way of using a vulnerability to cause a security violation. A laboratory demonstration against one version is not a universal attack against every installation.

Real incident

Unauthorised access or another security problem that has actually occurred. It is established through incident evidence, not just a research result.

What do verified examples from 2026 show?

On 7 May, Mozilla reported 271 security bugs identified with AI assistance and fixed in Firefox 150. They included 180 high-severity, 80 moderate-severity and 11 low-severity bugs. Mozilla explained that a high severity rating does not necessarily mean a practical attack is possible. A complete exploit was not developed for every bug. Several weaknesses may need to be combined to overcome the layers of protection.

This result demonstrates AI's value in security research. It does not describe 271 criminal attacks or 271 PHP vulnerabilities.

Mozilla's technical explanation of Firefox security improvements, 7 May 2026.

On 18 August, Mandiant described more than 100 critical vulnerabilities confirmed during two days of analysis. This was part of an investigation involving the theft of a company's code repositories. The team used a specialised system and expert verification. The result cannot be treated as an average for any website. The team describes testing hypotheses, identifying duplicate findings and rejecting false positives.

Google/Mandiant on AI-assisted source code review, 18 August 2026.

On 27 October, Anthropic published research demonstrating five exploit chains. It used an unreleased internal research model. The research was conducted in a controlled setting with coordinated vulnerability disclosure. The example shows the ability to develop an attack as well as find bugs. It does not establish that the model is publicly available or was used in a particular criminal campaign.

Anthropic's vulnerability research publication, 27 October 2026.

How can AI examine so much code?

A large project can be divided into several research tasks. One examines data processing, another access permissions and another connections between parts of the program. AI helps trace the logic and look for situations where intended restrictions might fail. Parallel work allows more possibilities to be examined.

A specialist must then check whether the situation can actually arise in the system, whether it is already known, which permissions are required and what an attacker could do. The fix must also be reviewed and tested. A headline about “hundreds of bugs” often leaves this work out. The studies above do not support a promise that one prompt to an AI tool will find hundreds of exploitable bugs on any website.

Criminals do not always need a new vulnerability

Google Threat Intelligence's report of 8 September describes a campaign observed in the second quarter of 2026 whose suspected motive was financial gain. After compromising a cloud environment, the attacker used AI agents to prepare and carry out a large credential-harvesting campaign in less than six hours. The report describes thousands of compromised third-party credentials.

Those numbers do not mean thousands of new vulnerabilities or compromised businesses. The example shows how AI can accelerate familiar tasks in a criminal campaign by helping prepare it, adapt tools and troubleshoot problems during execution.

Google GTIG/Mandiant on the misuse of AI, 8 September 2026. This is a provider's observation, not a statistical account of all attacks.

A stolen password, a forgotten test server or a module left unpatched for months can open the way to an attack. AI may help an attacker act faster, but access controls, updates and tested backups remain important. Microsoft's 2026 report also emphasises the role of identities, trusted access paths and people.

Microsoft Digital Defense Report 2026 summary, 1 October 2026.

You cannot infer AI involvement in a particular PHP attack merely from its speed or the number of requests. That requires separate evidence. On the defensive side, an AI tool's answer must also be verified before it becomes part of an incident's final findings.

What should businesses prepare for in the coming months?

Software support end dates can be checked, but future attacks cannot be predicted precisely. The following is our assessment for November 2026 and early 2027, based on the observations above. These are possible scenarios. Each business's risk must be assessed separately.

PHP 8.2 has a known security support end date

The PHP project's table lists 31 December 2026 as the end of security support for PHP 8.2. Installing the current critical fix and moving to a branch with a longer support period are two separate tasks. Do not delay the fix while waiting for that migration. Plan compatibility testing and the migration window now.

If your hosting provider offers extended maintenance for an old version, establish its scope and end date. An emergency fix for one flaw does not imply full ongoing support. Plan to move production systems to a supported stable release.

PHP's official supported versions table, checked again on 4 November 2026.

The gap between disclosure and attack attempts may shrink

In October's PHP case, attack attempts began before public disclosure. AI-assisted analysis may also accelerate work after a patch is published. Decide in advance who will respond to an urgent warning and how an emergency update will be deployed. A scheduled quarterly review is not sufficient for this kind of event.

Fraudulent messages may become more convincing

A message claiming to come from a hosting provider, bank or supplier may be grammatically sound and closely tailored to your business. Language quality is no longer a reliable test of authenticity. Verify requests to change payment details or grant access through a previously known channel, particularly when a message creates urgency and asks you to bypass normal procedures.

More findings will require more careful verification and prioritisation

The more possible flaws tools identify, the more important it becomes to check which ones actually affect the business's systems. Establish the impact and verify the fix. A hundred unassessed warnings are of little use if no one is assigned to investigate them and no deadline is set.

Include the company's AI chatbots and agents in the system inventory too. What data can they access? Can they change records, send email or use paid APIs? Who approves significant actions? The consequences of an account being compromised also depend on its permissions and connections.

A 30-day plan to prepare for the next warning

Use this plan while the system is operating normally. Do not postpone an active incident response, a critical fix or mandatory reporting until the week assigned below.

After this work, the business should have a system inventory, named responsibilities, a record of a recovery test and priorities for further work. Buying a security plugin alone will not provide these.

Questions businesses ask most often

The website looks normal. Could it still be hacked?

Yes. Unauthorised email, data access or administrator account creation may be happening in the background. Malicious code may be shown to only some visitors. Checking the appearance of the home page alone cannot establish the system's security.

Our hosting provider says PHP is updated. What else should we ask?

Ask which websites and runtimes received the fix, what the full package version is and how running processes were checked. Separately ask whether signs of compromise were investigated. Confirmation of an update is not the result of an incident investigation.

Is changing every password enough?

Password changes may be necessary, but the attacker's route into the system must also be closed. Check existing sessions, API access tokens, SSH keys and other mechanisms. If malware or a compromised management environment remains, new credentials may also reach the attacker.

Can a security scanner confirm that everything is clean?

A scanner's capabilities depend on its methods and the access it has. It is one source of information. Assess the result alongside files, accounts, logs, configuration and the incident timeline.

Must every attack attempt be reported to DVI?

No. The relevant questions are the facts of a personal data breach and the risk to people's rights and freedoms. Suspicions must still be investigated promptly, and a confirmed breach must be handled under the notification and documentation rules described above.

How much does recovery cost, and how long does it take?

That depends on the extent of the affected systems, available access, backup quality, evidence and whether connected services also need recovery. The first conversation establishes the immediate work and what still needs checking. Promising a precise deadline without that information would not be honest.

Would it be better to order a new website immediately?

First contain the damage and establish what is affected. A new website does not, by itself, resolve a compromised hosting account, an exposed mailbox or a shared infrastructure problem. After those checks, you can decide whether to restore, improve or rebuild the site.

CreateIT, recovery after an attack

We restore the services your customers use

We first contain the damage and close the route the attacker used, then verify and restore the functions your business needs. We examine files, the database and accounts, preserve information needed for investigation and assess recovery from a clean backup or in a clean environment.

We check whether the restored website can receive an enquiry, accept an order, process a payment and pass information to the right system. We work with WordPress, Drupal, Laravel and bespoke systems, including projects built by other developers.

We help establish which data and systems were at risk and prepare technical information for a notification. Your data protection specialist or legal adviser handles the legal assessment. We agree the start of the work and the immediate next steps during the first conversation.

For that conversation, have your domain, the signs you observed, when you noticed them and your hosting provider's name ready. Do not send passwords, secret keys or your customer database in the initial enquiry. We will agree a separate method for transferring access.

Recovery after an attack, security updates, website maintenance, cybersecurity.