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

**URL:** <https://community.thinlinc.com/t/ruling-out-that-the-2026-04-08-security-issue-was-exploited/1986>\
**Category:** Blog\
**Tags:** security\
**Created:** [22 April 2026 15:21 UTC](https://community.thinlinc.com/t/ruling-out-that-the-2026-04-08-security-issue-was-exploited/1986 "2026-04-22T15:21:44Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![wilsj](https://dub1.discourse-cdn.com/flex005/user_avatar/community.thinlinc.com/wilsj/32/554_2.png) [@wilsj](https://community.thinlinc.com/u/wilsj)\
**Post date:** [22 April 2026 15:21 UTC](https://community.thinlinc.com/t/ruling-out-that-the-2026-04-08-security-issue-was-exploited/1986/1 "2026-04-22T15:21:44Z")

</div>

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:

> [@ThinLinc 4.15.1 through 4.20.1 security release](https://community.thinlinc.com/t/thinlinc-4-15-1-through-4-20-1-security-release/1985):
>
> A security release is now available that fixes a critical security issue in ThinLinc’s browser-based web client, Web Access. This release is available for all supported versions of ThinLinc, meaning ThinLinc 4.15.0 through 4.20.0. More details about the upgrade process can be found in this post: [https://community.thinlinc.com/t/1983](https://community.thinlinc.com/t/1983) The vulnerability allowed any user with access to the system to impersonate any other user, including the root user. A multi-step authentication was required to e…

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:

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

```

```auto
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).

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`.

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`:

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

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.