Ruling out that the 2026-04-08 security issue was exploited

Knowledge Base
1

This post provides guidance for verifying that the vulnerability discovered on 2026-04-08 has not been exploited on a ThinLinc cluster. See this announcement for more information and instructions for updating your ThinLinc installation:

Note that we have not seen any indication that this vulnerability has been used by malicious actors in the wild.

Directly ruling out exploitation

If there have been no logins through Web Access, exploitation can be directly ruled out. This needs to be verified by looking at the Web Access log files on the master server(s).

There are two forms of lines in /var/log/tlwebaccess.log that indicate a login:

INFO tlwebaccess[120729]: [::ffff:10.47.4.80] User 'john' starting new session

INFO tlwebaccess[122657]: [::ffff:10.47.4.80] Redirecting user 'doe' to session 12 on agent thinlinc.example.com

In case there are historical logins, the vulnerability could only be exploited during a multi-step authentication. If you do not use one-time passwords, PAM login banners, password expiry, or PAM modules that present extra prompts, you are not affected by the issue.

If exploitation cannot be directly ruled out

In case exploitation cannot be ruled out, you can follow the instructions below to verify that no exploitation has occurred.

To reliably do this, auditd will need to have been present on the ThinLinc master server(s)š. Given that auditd is available, the following process can be used to find malicious activity:

  1. Compile a list of potential target users. This could be root, or users with access to restricted data.

  2. Find logins in the Web Access logs for the users of interest (see log line examples above) on the master server(s).

    These log lines indicate that a session has been started or resumed as the target user.

  3. Find log lines in the audit log on the same server with a similar timestamp as in the Web Access logs from the same IP. Check for type=USER_AUTH lines with exe=/opt/thinlinc/libexec/tl-pamapp and matching IP in hostname.

    These log lines show the users causing session start/resume in step 2.

  4. If the acct field in the audit logs in step 4 does not match the username in step 2, the exploit may have been used.

Example:

  1. We select root as a potential target user.

  2. The following suspicious login was identified in /var/log/tlwebaccess.log:

    2026-04-20 13:25:43 INFO tlwebaccess[120729]: [::ffff:10.47.4.80] User ‘root’ starting new session

  3. We search the audit log for authentication events coming from the IP in the log line above:

    $ sudo ausearch --message USER_AUTH --executable /opt/thinlinc/libexec/tl-pamapp --host ::ffff:10.47.4.80
    …
    time->Wed Apr 20 13:25:42 2026
    type=USER_AUTH msg=audit(1776757142.493:2992): pid=123993 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:thinlinc_webaccess_t:s0 msg=‘op=PAM:authentication grantors=pam_unix acct=“sauron” exe=“/opt/thinlinc/libexec/tl-pamapp” hostname=::ffff:10.47.4.80 addr=::ffff:10.47.4.80 terminal=? res=success’
    …

  4. Based on the acct field in the audit log, we can conclude that the user sauron from IP ::ffff:10.47.4.80 managed to initiate a session as root. Note the timestamps of the log lines. If the audit acct field in step 3 corresponds with the username in the log line in step 2, exploitation did not happen for the login attempt in question.

šSystem authentication events can also be seen in the system journal. However, those log lines are produced by the PAM modules responsible for the authentication. Hence, what the logs look like depends on your PAM configuration and will therefore vary in format and verbosity.

5 Likes
ThinLinc 4.15.1 through 4.20.1 security release