Bug: Attribute self correlation

[trizzosk]

Actual behavior

Attribute correlation shows event number of itself in current event.

I don't know if this is intentional or a bug.

Expected behavior

When viewing event with attributes, correlations shall not appear when correlated event id is the same as currently viewed event.

Steps to reproduce

Create event Insert attribute Refresh browser window with event -> correlation is shown (see screenshot)

Version

2.5.20

Operating System

Ubuntu

Operating System version

24.04 LTS

PHP version

8.3

Browser

Chromium on Debian 13

Browser version

Version 140.0.7339.127 (Official Build) built on Debian GNU/Linux 13 (trixie) (64-bit)

Relevant log output

Extra attachments

No response

Code of Conduct

• [x] I agree to follow this project's Code of Conduct

[trizzosk]

Event ID 20526 - see event id number in correlation and URL.

[github-germ]

I had discovered a bug prior to 2.5.21 with self correlating occuring in events, shared with @iglocska , and he fixed this in 2.5.21. I justed tested same and not seeing the issue anymore. If that is the same setup for you, consider upgrading to 2.5.21.

[trizzosk]

Hi @github-germ , I just update my instance to 2.5.21, and the attribute is still correlated to the same event. I tried to switch on/off correlations for the attribute. After I enabled correlation for the attribute I get the same event number (event itself...).

[github-germ]

Interesting. What Correlation engine are you using? I've switched in the MISP instance where I tested to the new OnDemand.

[trizzosk]

@github-germ I am using the "default correlation engine". So the "OnDemand" is the new? I haven't noticed that I shall switch the engine. I can do it anytime since I am the only admin/user of the instance.

[github-germ]

I'd suggest upgrading to 2.5.21 before playing with the OnDemand which is new. Suggest reading about it a bit before deciding if it makes sense with your MISP instance as it does not use db tables directly to manage correlations, i.e. the OnDemand produces correlations real-time via the queries that PHP performs. Hence, if you decide you want to switch back to default or no_acl correlations, I think you will need to rebuild correlations to "restock" the db tables that were not updated while running inOnDemand which can take a LONG time depending on the content size of your MISP instance.