You may sometimes see unknown or suspicious‑looking events in your Bloomreach project, for example, events containing:
SQL‑like strings (for example
UNION SELECT,DROP TABLE),Path traversal patterns (for example
../../),XML or code payloads,
Long gibberish strings.
These events do not automatically mean that someone is trying to hack you. In most cases, they are created when automated scanners or individuals send malicious or nonsensical data to your public tracking endpoint, and your project is configured to accept any event.
This article explains:
How to recognize these events
How to confirm what is happening
How to stop similar events from being stored in the future
How to clean up already stored data
Symptoms
You might notice one or more of the following:
New, unexpected event names appear in Data & Assets > Data Manager > Events that are not part of your implementation.
Event attributes contain:
SQL injection patterns,
File paths or OS commands,
Script fragments or XML entities,
Random or clearly non‑business text.
A small number of anonymous profiles (without clear identifiers) contain many of these suspicious events.
Why this happens
Public tracking endpoints
To track customer behavior, Bloomreach exposes public tracking endpoints (via JS SDK, mobile SDKs, or API). This is required so that browsers and apps can send data to Bloomreach.
Anyone who discovers your tracking token and endpoint can technically:
Call the tracking endpoint from a browser, script, or tool,
Send arbitrary event names and attributes.
If your project is configured to accept any event that reaches the endpoint:
Automated vulnerability scanners are testing your website.
Individuals “playing” with your endpoints can cause junk or attack‑like payloads to be stored as events in your project.
What this usually does not mean
By itself, this usually does not mean:
A breach of Bloomreach infrastructure
Unauthorized access to other customers’ data
Direct access to your internal databases through Bloomreach
It means:
Junk data was sent into your project via public tracking endpoints
Bloomreach stored this data because your configuration allowed it
You still need to treat the underlying traffic as a security matter on your side (for example, in your WAF or application). Still, it is not typically an exploit of the Bloomreach platform itself.
Step 1 – Confirm that the events are suspicious
Open Data & Assets > Data Manager > Events.
Look for:
Event types you do not recognize.
Event types whose example payloads contain:
SQL commands,
File paths,
Code snippets,
Long random strings.
For an example event, navigate to a customer profile that contains it (if available).
On the profile:
Check whether it has valid identifiers (
email, customer ID, and more).Check whether it contains legitimate activity (orders, real page views) or mostly nonsense.
Typical attack pattern
One or a few profiles
Little to no real customer data
Many nearly identical events with gibberish or attack payloads
Step 2 – Prevent similar events in the future
2.1 Restrict which events can be stored (Data Manager)
In many projects, you can configure Bloomreach only to accept events that are defined in Data Manager:
Review your event definitions in Data & Assets → Data Manager → Events.
Ensure that all legitimate events used by your implementation are defined there.
If your project offers this option, enable the setting that rejects or ignores events that are not defined in Data Manager (button is blue if active):
Effect
Defined, legitimate events keep working.
Random or scanner‑generated events with unknown names are no longer stored.
2.2 Strengthen your own application security
Even if Bloomreach rejects undefined events, scanners may still send malicious traffic to your website or app. To reduce this at the source, use your existing security tools; however, this is out of scope for this troubleshooting guide.
Step 3 – Cleaning up existing suspicious data
If your project falls victim to such data, the most important steps are deleting the data and preventing further contamination.
3.1 Deleting fake profiles
If suspicious events are concentrated in a few clearly non‑real profiles, you can:
Open each such customer profile in the UI.
Confirm it contains only junk data and no real customer information.
Delete the profile using the standard delete option:
This helps:
Remove those profiles from customer lists and analyses.
Reduce the visible impact of the junk data.
3.2 Removing unwanted event types
If you see event types that are clearly not part of your implementation and only contain junk:
Use Data Manager → Events to remove these event definitions once you have confirmed they are not used anywhere in your setup
The event shown in the screenshot is not currently used in the project (that is, it is not present in any customer profile). This is also visible on the right thanks to the red button. If the button were green, it would indicate it is actively in use, and you would not be able to delete it.
There is no generic, one‑click bulk deletion in the UI to remove only some events based on complex conditions.
In practice, customers usually:
Delete fake profiles.
Remove fake event types.
Accept that any remaining remnants are limited and will not grow further after protections are in place.
Step 4 – Evaluating the impact
When you discuss this internally (for example, with your security team), you can summarize the situation as follows:
What happened
Attackers or scanners sent malicious or nonsensical payloads to your public tracking endpoint.
Because your configuration allowed any event to be tracked, these payloads were stored as events.
What this means for your data
Bloomreach stored exactly what was sent to it.
By default, this does not provide attackers with direct access to your Bloomreach project or databases.
What is under your control
Which event types and attributes do you track
Whether undefined events are accepted or rejected
How to secure your website/app and network (WAF, firewalls, validation, and more)
Best practices to avoid this in the future
Keep your Data Manager configuration up to date:
Define all events you use.
Reject undefined events if the option is available.
Regularly review:
Event usage dashboards (where available) for unexpected spikes.
New event types or attributes that were not part of your original design.