Available for projects & agency overflow · Quick reply, from the person who does the work

Send a message contact@allaux.fr
FR EN TR
allaux.
Emergency Discuss my project

My shop name is displaying text I never wrote

A fragment of code turns up in the footer, in the browser tab or in order emails: the configuration value holding your shop name was written to directly in the database, and it is being used as a carrier.

Describe my issue Send a message

A display bug that isn’t one

The symptom is always described the same way: there is gibberish in the footer, the browser tab shows code, the shop name is broken in order emails. The usual instinct is to look for a bad translation, a misconfigured theme, a character that went sideways during an import. It almost never is.

The shop name is not theme text. It is a configuration value stored in the database under the key PS_SHOP_NAME. The shop reads it back and reprints it in dozens of places: header, footer, document title in the browser tab, transactional emails, invoices, internal notifications. One row in the database, served everywhere, and not always handled the same way depending on where it reappears.

That is what makes it a useful target. An attacker needs no theme file change, no edit to the checkout, no file left on the server. They write once into a configuration value, and the content is then served on every page, to every visitor, including those in the middle of paying. The odd text in your footer isn’t the problem: it is the visible part of a chain whose remainder is silent.

What should put you on alert

  • A tag or code fragment visible in the footer, where the shop name normally appears.
  • A browser tab title containing text you never typed.
  • The shop name mangled in order confirmation emails or on invoices.
  • A shop name field that looks fine in the back office while the public site shows something else.
  • A script you don’t recognise in the page source, including on the checkout.
  • Customers reporting that they were asked for their payment details twice.

What PrestaShop documented in January 2025

On 22 January 2025 PrestaShop issued an official alert about a wave of attacks exploiting SQL injection flaws in third-party modules rather than in the core. The method described is exactly this one: attackers insert malicious content into the PS_SHOP_NAME configuration value stored in the database; that value is then used to load unauthorised JavaScript which captures customer input. The recommended check is easy to state: look for a script or unexpected content inside the PS_SHOP_NAME value, in the database.

That JavaScript is not there to spoil your layout. It is there to read what customers type during checkout: contact details, address, payment information. In the more polished campaigns, the overlay is careful: a fake payment form appears first, the customer enters their card, then the real form asks for the same details again. Most customers accept the double entry and complete the order without suspecting the data has already been stolen. Which is why this symptom cannot be treated as cosmetic.

On the fix side, PrestaShop released a patched version of the official ps_contactinfo module, 3.3.3, compatible with PrestaShop 1.7.2 and above, under GitHub advisory GHSA-35pq-7pv2-2rfw. The official recommendations go further: update every native and third-party module, use a custom database prefix rather than the default one, deploy a web application firewall, keep regular backups and follow PrestaShop security advisories.

Lecture seule : valeur réellement stockée en base
SELECT name, value FROM ps_configuration WHERE name = 'PS_SHOP_NAME';

Why read the database value rather than the back office field

The query above only reads; it changes nothing. Replace the ps_ prefix with your own: if you followed the advice about a custom prefix, your table is named differently.

Why go to the database instead of the back office field? Because the back office renders the value inside a form, and a form escapes, truncates or hides part of what it receives. A value that looks harmless in an input box can contain something quite different once served in a page. Reading the database gives you the raw value, the one that is actually stored, with no display layer in between. It is the only check that settles the question.

The default prefix plays a direct part here. A write aimed at a table has to know that table’s name. With the standard prefix, that name is identical across hundreds of thousands of shops: nothing to work out, and an attack written once applies everywhere unchanged. Changing the prefix fixes no vulnerability and is no protection in itself; PrestaShop recommends it precisely because it removes a free convenience handed to automated attacks.

What I do, in this order

  1. Read the raw value in the database

    Use the read-only query above, adjusted to your prefix. You are looking for a script or unexpected content inside the value, not merely a misspelt name.

  2. Compare with what the public page actually serves

    View the page source and look wherever the shop name is reprinted: header, footer, document title. A gap between the database and the page shows you where the value is being reinterpreted.

  3. Check the theme files

    The configuration value is not the only possible carrier. Script tags can also be injected straight into theme files, particularly in templates loaded on every page. Compare the theme against a clean copy.

  4. Fix the value, then hunt down the write

    Restoring a clean shop name makes the symptom disappear in minutes. It tells you nothing about how the value was written. While the module that allowed that write is still in place, the value can be rewritten.

  5. Update every module

    That is the first official recommendation: native modules as well as third-party ones. The official ps_contactinfo module has a fixed release, 3.3.3, compatible with PrestaShop 1.7.2 and above.

  6. Treat the incident as a possible data breach

    If unauthorised JavaScript was served on checkout pages, customer input may have been captured. That carries notification duties, and it needs documenting: dates, pages affected, how long the exposure lasted.

Related reading

Describe your need in one minute

A few targeted questions so I can reply with an estimate rather than another questionnaire.

constat
plateforme
depuis-quand (facultatif)
sauvegarde
Please provide an email or a phone number so I can get back to you.

Please provide an email or a phone number so I can get back to you.

Frequently asked questions

The field looks normal in the back office. Is that a good sign?
No, it settles nothing. The back office renders the value inside a form that may escape or truncate it. Only a direct database read gives you the raw value as it is served to visitors.
I put the correct shop name back and everything looks fine. Is it fixed?
The symptom is gone, not the cause. The method PrestaShop described in January 2025 runs through an SQL injection flaw in a third-party module. If that module is still there in a vulnerable version, the value can be rewritten.
Why target the shop name rather than one specific page?
Because it is reprinted everywhere: header, footer, tab title, transactional emails, invoices. A single database write is enough for the content to be served across the whole site.
Does changing the database prefix really protect me?
It is not a protection in itself; no flaw is fixed by that change. PrestaShop recommends it because the default prefix makes table names identical everywhere, which makes automated attacks easier.
Are my customers affected?
If unauthorised JavaScript was loaded on checkout pages, assume input may have been captured. Handle it as a possible personal data breach, with the record-keeping and notifications that go with it.

Related pages