[Bug Report] Incorrect process detected

[tredondo]

Describe the bug:

I haven't been able to reproduce this issue precisely, but I've seen it several times: when the GUI shows consecutive connection attempts from a process that would absolutely never connect to those domains (e.g. a brokerage API gateway trying to connect to WhatsApp or Meetup).

Include the following information:

• OpenSnitch version: 1.8.0
• OS: Ubuntu 24.04
• Window Manager: KDE
• Kernel version: 6.14.0-123037 #37~24.04.1tux2 SMP PREEMPT_DYNAMIC Fri Jan 23 22:31:21 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

To Reproduce:

Steps that exhibited the behavior:

1. In a browser, open tabs for sites that initiate connections in the background: Facebook, WhatsApp, Meetup, LinkedIn, YouTube
2. Don't create rules for these sites. Create a rule to allow everything from the browser command line for a duration (I used 12h, but hopefully 5m will reproduce the issue)
3. Have some other applications running. In my case I have this brokerage API, which works without needing a broker account
4. (Leave the machine unattended) After the duration above, the browser may initiate connections to Facebook, WhatsApp, Meetup domains
5. OpenSnitch may display these as originating from the other application.

Screenshots:

Additional context:

Maybe #1315?

[gustavo-iniguez-goya]

Please, change manually the LogLevel to -1 in /etc/opensnitchd/default-config.json, and reproduce the issue.

Also if you click on the info icon, in the top right of the pop-up, you can copy the PID and execute: ls -l /proc/<pid>/exe to know the real path of the process.

[tredondo]

Haven't yet changed the log level, but the PID did resolve to /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, which should absolutely not be the case.

Interesting that in the info box, the domain isn't logged.

Is it possible that the executable was identified correctly, but the domain looked up was not?

UDP 53858:127.0.0.1 -> 127.0.0.53:53 

Path:      /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java
Cmdline: java -server -Dvertx.disableDnsResolver=true -Djava.net.preferIPv4Stack=true -Dvertx.logger-delegate-factory-class-name=io.vertx.core.logging.SLF4JLogDelegateFactory -Dnologback.statusListenerClass=ch.qos.logback.core.status.OnConsoleStatusListener -Dnolog4j.debug=true -Dnolog4j2.debug=true -cp root:dist/ibgroup.web.core.iblink.router.clientportal.gw.jar:build/lib/runtime/* ibgroup.web.core.clientportal.gw.GatewayStart --conf ../root/conf.yaml
CWD:      /apps/IB-clientportal.beta.gw
MD5:       
UID:         1000
PID:         211167

Process tree:

│1  /usr/lib/systemd/systemd
│2223      \_ /usr/lib/systemd/systemd-executor
│2223          \_ /usr/lib/systemd/systemd


Environment variables:
LOGNAME=ted
KONSOLE_DBUS_SERVICE=:1.102
PAM_KWALLET5_LOGIN=/run/user/1000/kwallet5.socket
_=/usr/bin/java
KONSOLE_DBUS_WINDOW=/Windows/1
KDE_SESSION_VERSION=6
XDG_VTNR=2
TERM=xterm-256color
LC_MONETARY=en_US.UTF-8
LANGUAGE=
LANG=en_US.UTF-8
XDG_MENU_PREFIX=plasma-
SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh
COLORFGBG=15;0
SYSTEMD_EXEC_PID=2347
WAYLAND_DISPLAY=wayland-0
KGLOBALACCELD_PLATFORM=org.kde.kwin
SHELL_SESSION_ID=178f18dc198449f4a90f472bbab3c0b7
LC_PAPER=en_US.UTF-8
COLORTERM=truecolor
INIT_CWD=/prg/ib-gateway-service
LC_NAME=en_US.UTF-8
XDG_SESSION_ID=3
XDG_CURRENT_DESKTOP=KDE
MEMORY_PRESSURE_WRITE=c29tZSAyMDAwMDAgMjAwMDAwMAA=
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
RUNTIME_PATH=root:dist/ibgroup.web.core.iblink.router.clientportal.gw.jar:build/lib/runtime/*
npm_config_user_agent=deno/2.6.8 npm/? deno/2.6.8 linux x86_64
XDG_SESSION_DESKTOP=KDE
XDG_SEAT=seat0
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MEMORY_PRESSURE_WATCH=/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/session.slice/plasma-kwin_wayland.service/memory.pressure
LC_ADDRESS=en_US.UTF-8
DEBUGINFOD_URLS=https://debuginfod.ubuntu.com 
WINDOWID=110152934691024
ICEAUTHORITY=/run/user/1000/iceauth_RwuxZY
HOME=/home/ted
DISPLAY=:0
XKB_DEFAULT_LAYOUT=us
__VK_LAYER_NV_optimus=NVIDIA_only
SHLVL=2
LC_IDENTIFICATION=en_US.UTF-8
KDE_SESSION_UID=1000
KONSOLE_VERSION=250802
USER=ted
MANAGERPID=2223
KDE_FULL_SESSION=true
XKB_DEFAULT_MODEL=pc105
QT_WAYLAND_RECONNECT=1
XDG_CONFIG_DIRS=/home/ted/.config/kdedefaults:/etc/xdg
KDE_APPLICATIONS_AS_SCOPE=1
LC_TIME=en_US.UTF-8
QT_ACCESSIBILITY=1
SHELL=/bin/bash
PATH=[...]
GTK_RC_FILES=/etc/gtk/gtkrc:/home/ted/.gtkrc:/home/ted/.config/gtkrc
XDG_SESSION_TYPE=wayland
PWD=/apps/IB-clientportal.beta.gw
XDG_SESSION_CLASS=user
INVOCATION_ID=cdf0a5d929cd426a9644bcee23103bc1
LC_MEASUREMENT=en_US.UTF-8
LESSCLOSE=/usr/bin/lesspipe %s %s
_JAVA_AWT_WM_NONREPARENTING=1
LC_NUMERIC=en_US.UTF-8
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/ted/.gtkrc-2.0:/home/ted/.config/gtkrc-2.0
JOURNAL_STREAM=9:26864
KONSOLE_DBUS_SESSION=/Sessions/1
EDITOR=mcedit
DRI_PRIME=1
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
SYSTEMD_PAGER=less
GSM_SKIP_SSH_AGENT_WORKAROUND=true
DESKTOP_SESSION=plasma
XDG_RUNTIME_DIR=/run/user/1000
XAUTHORITY=/run/user/1000/xauth_iUbeyP
PROFILEHOME=
LESSOPEN=| /usr/bin/lesspipe %s 

[tredondo]

Please, change manually the LogLevel to -1 in /etc/opensnitchd/default-config.json, and reproduce the issue.

Tried that, ran into #1529. What should I do?

[gustavo-iniguez-goya]

sorry @tredondo , these are the steps:

• change the LogLevel to -1
• truncate the log (as root): $ sudo truncate -s0 /var/log/opensnitchd.log
• reproduce the issue.
• change LogLevel to 2, and post the log file /var/log/opensnitchd.log

Haven't yet changed the log level, but the PID did resolve to /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, which should absolutely not be the case.

mmh, I'd say then that the PID is correctly being identified. There're also traces to the java process in the environment variables:
RUNTIME_PATH=root:dist/ibgroup.web.core.iblink.router.clientportal.gw.jar:build/lib/runtime/*

Is it possible that the executable was identified correctly, but the domain looked up was not?

Yes, it could be the case. A few days ago I added a change to reset the widgets before displaying a new pop-up 4c16729, because I observed a weird behaviour.

But the logs will tell if something is wrong.

In the log, new process executions look like this:
DBG [eBPF exec event] type: 1, ppid: 117541, pid: 117544, uid: 0, /usr/bin/tar -> [tar -x -m -f - --warning=no-timestamp]

when a new outbound connections is established, the PID should already have the process details in cache:

IMP  new connection udp => 53637:192.168.1.104 -> 1.1.1.1 (alive.github.com):53 uid: 1000, mark: 0
DBG  [ebpf conn] not in cache, but in execEvents, pid: 2158371, uid: 1000 -> /usr/lib/firefox-esr/firefox-esr -> [/usr/bin/firefox-esr]
DBG  [ebpf conn] adding item to cache: udp53637192.168.1.1041.1.1.153

[jamcinnes2]

I think I have experienced this. I have opensnitch running in a Linux VM host. I have a guest VM running a web browser. The guest VM is using a dnsmasq based bridge network so DNS lookups on the guest are going through dnsmasq on the host. Sometimes when the guest-VM-browser tries to resolve a hostname, I get an opensnitch popup on the host. The hostname is right but the process name seems to be a random malfunction. For example it told me that "arduino-ide" is trying to access "spotify.com". Arduino was running on my host, and spotify in a browser on the guest VM. A while later another opensnitch popup that "Qt6WebEngine" is trying to access "cdn.spotify.com".

Hope I explained that well enough, i know its complicated. The popup seems to be valid, it is just that the process name isn't making sense. It should probably be "dnsmasq".

[gustavo-iniguez-goya]

thanks for the explanation @jamcinnes2 !

If you can reproduce it, please, follow the steps above and post the logs.

[tredondo]

I saw this issue again, I think, does this help?

OpenSnitch.repeated.prompts_20260211_122135.webm