News, updates, trends and the latest
info you need to know about IT

Overview
Authlib (versions up to and including 1.7.2) contain a signature‑verification bypass in the JSON Web Signature (JWS) general JSON serialization handling. The JsonWebSignature.deserialize_json() function accepts a JWS object with an empty “signatures” array and treats the payload as successfully verified, allowing attackers to supply arbitrary forged content without possessing any key material.
Description
Authlib is a Python library that provides tools for implementing OAuth, OpenID Connect, JWT/JWS/JWE (JSON Web Token / JSON Web Signature / JSON Web Encryption), and other modern authentication and authorization standards. It’s widely used in web applications and microservices to handle token creation, cryptographic validation, and secure communication.
As discussed in CVE-2026-96760, a security flaw in Authlib’s handling of JSON Web Signatures (JWS) makes it possible for an attacker to skip signature verification completely. Normally, a JWS should include at least one valid signature to prove the data hasn’t been tampered with. However, Authlib’s deserialize_json() function mistakenly accepts JWS objects even when the “signatures” section is an empty list. Because the function starts by assuming the signatures are valid and never performs any checks when the list is empty, it ends up treating unsigned data as if it were properly signed. This means an attacker could provide a JWS with no signatures, and Authlib would still treat it as trusted. Both ways of loading a JWS in Authlib are affected:
jws.deserialize_json(“payload”:”…”, “signatures”:[], key=None)
jws.deserialize(‘”payload”:”…”,”signatures”:[]’, key=None)
Impact
An attacker can forge arbitrary authenticated payloads without any signing key or credentials. Systems that rely on Authlib’s JWS verification for authentication, authorization, inter-service message integrity, or signed configuration data may accept attacker‑supplied content as legitimate. Potential attack scenarios inlcude the following:
* Authentication bypass: forged identity or privilege‑escalation claims (e.g., sub=admin).
* Signed message injection between microservices using JWS.
* Forged authorization claims such as scopes, roles, or permissions.
* Integrity bypass in systems relying on signed JWS data.
Solution
The vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing. Users are advised to monitor the project’s GitHub repository for updates and install the latest version of this library once a fix has been released.
Acknowledgements
Thank you to Tong Hoang Gia (uziii2208) and Nguyen Minh Tuan (nguyenminhtuan28) for reporting this vulnerability. This document was written by Bob Kemerer.

Overview
Three cross-site scripting (XSS) vulnerabilities identified in Readwise Reader for Android version 8.7.2 are disclosed. An attacker with the ability to craft malicious documents or metadata can exploit these vulnerabilities by supplying poisoned content that bypasses sanitization. Successful exploitation could allow the attacker to execute arbitrary JavaScript within the application’s WebView context and compromise the confidentiality and integrity of user data, including access to stored documents, credentials, and session tokens.
Description
Readwise Reader from Readwise is designed to provide a unified read-it-later service that helps individuals collect and organize articles, newsletters, videos, and other content of interest into a single reading interface. It is available on multiple platforms including Android and can synchronize content across devices.
CVE-2026-18311: A stored cross-site scripting (XSS) vulnerability in the header rendering component in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via crafted document metadata fields. The header rendering component is impacted due to insufficient HTML escaping of metadata fields such as ‘doc.author’ and ‘doc.title’, which allows malicious scripts to be stored in the user’s library and synchronized to Android devices where they are executed in the WebView context.
CVE-2026-18312: A stored cross-site scripting (XSS) vulnerability in the WebView URL construction logic in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via malicious URL metadata. The WebView URL construction for X (formerly Twitter) video fallback and iOS paywall messages is impacted due to improper escaping of URL metadata before interpolation into href attributes, which allows user-controlled values to break out of the URL structure and inject script elements that are inserted into the DOM via innerHTML.
CVE-2026-18320: A stored cross-site scripting (XSS) vulnerability in the article body sanitization component in Readwise Reader for Android version 8.7.2 allows remote attackers to execute arbitrary JavaScript via malicious SVG markup. The sanitize-html configuration is impacted due to a wildcard attribute rule that permits all attributes on SVG and PATH elements, which allows script-capable attributes such as onload and onerror to bypass sanitization.
Impact
An attacker with the ability to create or modify documents accessible to Readwise Reader can supply documents containing malicious metadata or markup that bypasses sanitization and is subsequently stored in users libraries. Because these documents are synchronized to Android devices and rendered within the Reader WebView, each vulnerability enables stored XSS: CVE-2026-18311 and CVE-2026-18312 through poisoned metadata, and CVE-2026-18320 through malicious SVG markup.
Solution
Unfortunately, the vendor could not be reached to coordinate this issue. Users should apply vendor updates as they become available (check Vendor Information section for updates) and keep Readwise Reader updated through the Google Play Store. As of publication, version 8.10.1 includes a patch that addresses the sanitizer-wildcard issue. Additionally, users should exercise caution when adding content from untrusted sources to their reading library and consider manually reviewing document metadata before saving articles to minimize exposure to malicious content.
Acknowledgements
Thanks to Zampier Zago (FUNFACTOR1) for reporting these vulnerabilities. This document was written by Alex Lewis.

Overview
ViewSonic vCast software, which is included in ViewBoard smartboard devices, contains multiple vulnerabilities that an attacker can chained to achieve full device compromise.
Description
ViewSonic ViewBoards are widely used smart display devices (smartboard), typically deoloyed in enterprise and educational environments. vCast is ViewSonic’s proprietary software suite for wireless connection between smartboards, which are Android-based systems, and devices running a client application. Three distinct vulnerabilities, all invoking unauthenticated endpoints, have been identified within the vCast suite.
CVE-2026-82989
vCast’s media streaming service allows a remote attacker to exfiltrate JPEG images of screen content via GET requests to an unauthenticated /snapshot or /screen API endpoint.
CVE-2026-82988
vCast’s Android Package Kit (APK) delivery mechanism allows a remote attacker to trigger unprivileged file installation by providing a malicious APK URL through an unauthenticated download endpoint.
CVE-2026-82987
vCast’s network services allow a remote attacker to inject arbitrary input into service endpoints via HTTP requests to exposed unauthenticated endpoints
Impact
An unauthenticated attacker can chain these vulnerabilities via a shared network to deliver and execute arbitrary code on a vCast-based device without user interaction. Potential device-level impact includes unauthorized access to displayed content, persistent installation and execution of arbitrary applications, and full compromise of the device. Additionally, an exploited device’s connected network may be prone to lateral movement.
Solution
Unfortunately, ViewSonic could not be reached to coordinate the vulnerability. In the meantime, firmware updates should be applied when available. If possible, segment vCast devices onto an isolated, secure network with strict controls, separate from systems containing sensitive data. Network activity should be monitored for suspicious vCast connections.
Acknowledgements
Thank you to Adam Mohammed Zenker for this report. This document was written by Alexander Lewis.