<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
  <title>Vulnerabilities! - Zero Science Lab</title>
  <description>Zero Science Lab - Macedonian information security research and development laboratory</description>
  <link>https://www.zeroscience.mk</link>
  <language>en-us</language>

  <lastBuildDate>Thursday, 08 Oct 2026 10:32:47 +0200</lastBuildDate>

  <image>
    <title>Zero Science Lab</title>
    <width>144</width><height>400</height>
    <link>http://www.zeroscience.mk</link>
    <url>https://www.zeroscience.mk/images/rss.gif</url>
  </image>

<item>
<title>Apache Avatica 1.29.0 JDBC Connection Property Injection</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6013</link>
<pubDate>Thursday, 08 Oct 2026 10:30:00 +0200</pubDate>
<description>Apache Calcite Avatica (avatica-server) copies client-supplied JDBC connection properties into the backend connection with no filtering by default (JdbcMeta.openConnection: fullInfo.putAll(info) then DriverManager.getConnection), and authentication is disabled by default, so an unauthenticated remote client can inject driver properties such as allowLoadLocalInfile or autoDeserialize.</description>
</item>

<item>
<title>Apache OzHera 2.2.6 Authenticated SQL Injection</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6012</link>
<pubDate>Thursday, 08 Oct 2026 13:28:00 +0200</pubDate>
<description>Apache OzHera is affected by a SQL injection vulnerability in its Doris-backed log search. In EsDataServiceImpl, the log-search query is built by string-interpolating user-supplied request parameters and executed on a plain Statement (createStatement().executeQuery) with no parameterization or escaping, against the Doris log store. The injectable parameters are the full-text search term (fullTextSearch, spliced as a WHERE condition in buildQuerySql and in the statistics path buildQuerySqlConditional), the sort key (sortKey, spliced after ORDER BY), and the tail selector (tail, quoted and spliced into a tail IN (...) clause). Numeric parameters (startTime/endTime/page/pageSize) are not injectable, and Elasticsearch-backed log stores use a different, unaffected code path. An authenticated console user can inject SQL and read data beyond the intended query, including other tables and log stores within the same Doris instance.</description>
</item>

<item>
<title>Apache SeaTunnel 3.0.0 Remote Code Execution</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6011</link>
<pubDate>Wednesday, 07 Oct 2026 20:19:00 +0200</pubDate>
<description>Apache SeaTunnel is affected by an unauthenticated remote code execution condition in its engine REST API. The REST API v2 ships with authentication disabled by default (enable-basic-auth defaults to false), so no authentication filter is installed, and the job-submission endpoint POST /submit-job accepts a job configuration that may contain a DynamicCompile transform. That transform compiles the job-supplied source_code through an unsandboxed new GroovyClassLoader().parseClass(...) with no SecureASTCustomizer and executes it on the engine node when the transform schema is resolved. A remote party able to reach the REST port can therefore submit a single job whose Groovy (or Java/Scala) source runs arbitrary commands on the SeaTunnel engine node without any credentials.</description>
</item>

<item>
<title>Apache Ratis 3.3.1 Java Deserialization</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6010</link>
<pubDate>Wednesday, 07 Oct 2026 00:02:00 +0200</pubDate>
<description>Apache Ratis suffers from an unsafe Java deserialization vulnerability in its RPC error handling. The cause and stack-trace bytes carried in an RPC reply exception are deserialized through IOUtils.readObject with no class filtering, so a malicious server (or a man-in-the-middle) can return a crafted exception whose bytes are deserialized in the receiving client. A gadget chain was run through the real IOUtils.readObject in ratis-3.3.1. This can result in remote code execution against a Ratis client where a suitable gadget is present on the client classpath. The trust precondition is a compromised/malicious server or MITM, so a peer-trust rebuttal is likely.</description>
</item>

<item>
<title>Apache Curator 5.9.0 Java Deserialization</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6009</link>
<pubDate>Tuesday, 06 Oct 2026 18:41:00 +0200</pubDate>
<description>Apache Curator suffers from an unsafe deserialization vulnerability in its service-discovery component. The discovery payload is deserialized with Jackson polymorphic typing configured as Id.CLASS, which lets the serialized data name the Java class to instantiate, so an attacker who can publish a crafted discovery record (via ZooKeeper write access or rogue-service registration) can drive gadget-based deserialization on a consumer that reads it, resulting in remote code execution where a suitable gadget is present on that consumer's classpath.</description>
</item>

<item>
<title>Apache Commons JCS 3.2.1 Unauthenticated Java Deserialization</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6008</link>
<pubDate>Tuesday, 06 Oct 2026 14:24:00 +0200</pubDate>
<description>Apache Commons JCS suffers from an unauthenticated Java deserialization vulnerability on its TCP Lateral Cache. The lateral listener deserializes incoming objects through an ObjectInputStream guarded only by a three-prefix class denylist, which is bypassable with widely available gadgets, so a remote attacker who can reach the lateral port can send a crafted object and execute code. On deployments that enable the TCP lateral cache this is unauthenticated remote code execution.</description>
</item>

<item>
<title>Apache Submarine 0.8.0 Authentication Bypass / Remote Code Execution</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2006-6007</link>
<pubDate>Monday, 05 Oct 2026 13:52:00 +0200</pubDate>
<description>Apache Submarine (retired to the Apache Attic) suffers from an authentication bypass leading to unauthenticated remote code execution. The security filter CommonFilter.isProtectedApi() treats any request whose User-Agent header matches the Python SDK pattern as not requiring authentication, and the User-Agent header is fully attacker-controlled, so any client that sets that header reaches every protected REST endpoint with no token. Through the experiment API an attacker can define the container image and command of a job, which are placed directly onto the launched Kubernetes pod, resulting in unauthenticated remote code execution on the cluster and full administrative takeover via the user-management APIs.</description>
</item>

<item>
<title>Apache Karaf 4.4.11 JAAS LDAP Login Modules LDAP Filter Injection</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6006</link>
<pubDate>Monday, 28 Sep 2026 13:50:00 +0200</pubDate>
<description>Apache Karaf's JAAS LDAP login module is affected by LDAP filter injection. The user and role LDAP search filters are built in LDAPCache by string substitution: each placeholder (%u for the username, %dn for the user DN, %fqdn for the fully qualified DN) is inserted with java.util.regex Matcher.quoteReplacement followed by doubling backslashes, which is regex-replacement escaping, not RFC 2254 / RFC 4515 LDAP filter escaping. The filter construction itself therefore does not neutralize LDAP metacharacters, it relies on the caller to have encoded the values. The login module does pre-encode the username with Util.doRFC2254Encoding before the user search, but the role search filter also substitutes the DN values (%dn, %fqdn) with no LDAP escaping, and the filter builder performs none of its own. As a result a value that reaches the filter without prior encoding is not neutralized and can alter the LDAP query.</description>
</item>

<item>
<title>Apache BuildStream 2.8.0 (symlink) Arbitrary File Write</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6005</link>
<pubDate>Thursday, 24 Sep 2026 01:23:00 +0200</pubDate>
<description>Apache BuildStream's tar source plugin extracts archives without safely resolving symbolic links (link following). A malicious source tarball can include a symlink entry that points outside the staging directory and then a file entry that writes through it, so a crafted upstream source can create or overwrite files on the host with the privileges of the user running BuildStream, as part of source fetching. On Python &lt; 3.12 the plugin relied on an incomplete internal check (_assert_safe, which skipped symlink members and used a buggy basename/prefix comparison) as the only guard. The fix replaces that check with a custom extraction filter built on the Python tarfile data and tar filters, applied on all Python versions (using a local copy of tarfile.py on Python &lt; 3.12).</description>
</item>

<item>
<title>Apache PDFBox 3.0.8 Flate PNG Predictor Disproportionate Heap Allocation DoS</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6004</link>
<pubDate>Sunday, 20 Sep 2026 23:55:00 +0200</pubDate>
<description>The library is prone to a denial of service condition caused by a disproportionate heap allocation in the Flate decode PNG predictor path. When a stream is filtered with FlateDecode and a predictor is declared, PDFBox sizes an internal decoding buffer directly from the PDF-supplied decode parameters (/Columns, /Colors and /BitsPerComponent) inside org.apache.pdfbox.filter.Predictor. The /Columns value is taken from the untrusted document and is not bounded against the actual stream length, so a crafted stream a few hundred bytes in size forces an allocation of hundreds of megabytes. A confirmed 396 byte PDF drives an allocation of roughly 250 MB inside Predictor$PredictorOutputStream.&lt;init&gt;, and under a constrained heap the process terminates with java.lang.OutOfMemoryError. The condition is reached during normal document processing when the affected stream is decoded (content stream, object stream, image XObject or cross-reference stream), requires no authentication and no user interaction beyond submitting a PDF to a feature that already accepts one. PDFBox guards the integer overflow case, throwing an IOException (&quot;Calculated row length is negative&quot;) for values that wrap negative, but the large positive range remains unbounded. A related unbounded FlateDecode output buffer (decompression bomb, a small stream inflating to gigabytes) amplifies the same denial of service class.</description>
</item>

<item>
<title>Apache Impala 4.5.1 Insufficient Authorization Remote Code Execution</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6003</link>
<pubDate>Friday, 11 Sep 2026 14:14:00 +0200</pubDate>
<description>Apache Impala versions 2.7.0 through 4.5.1 suffer from an insufficient authorization vulnerability that leads to remote code execution. A table created with STORED BY JDBC takes a driver.url property that Impala uses to fetch a remote JAR and load the named driver class on first query, and the driver.url and driver.class properties are not authorization-checked. An authenticated user who can create such a table can therefore point it at an attacker-controlled location and have code loaded and run on the Impala daemon hosts. The related CREATE DATA SOURCE path in CreateDataSrcStmt.java also carries a literal &quot;// TODO: authorization check&quot; where the privilege check belongs.</description>
</item>

<item>
<title>LightFTP Server 2.4 Race Condition</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6002</link>
<pubDate>Friday, 07 Aug 2026 10:00:00 +0200</pubDate>
<description>LightFTP through version 2.4 (current master, commit d28c5e0) contains multiple data races in ftpserv.c caused by unsynchronized access to the shared FTPCONTEXT between a connection's control thread and its data-transfer worker thread. In worker_thread_cleanup(), invoked by the anonymous-reachable ABOR command, the control thread reads and writes context-&gt;data_socket, context-&gt;data_ipv4, and context-&gt;worker_thread_abort with no lock, while the detached worker thread (list_thread and its siblings) concurrently uses the same data socket and writes context-&gt;worker_thread_valid.

Version 2.4 removed the MTLock mutex that previously guarded this state and replaced it with an atomic busy compare-and-swap that only serializes worker startup, not cleanup against a running worker, so the control thread closes and clears the data connection while the worker is still operating on it. ThreadSanitizer confirms data races at at least 16 distinct source locations (5 in worker_thread_cleanup), reproducible by an anonymous user with LIST followed by ABOR. The per-run report count is higher and scales with concurrency. The impact is undefined behavior with potential denial of service; a crash on a standard release build was not demonstrated.</description>
</item>

<item>
<title>LightFTP Server 2.3.1 Race Condition</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6001</link>
<pubDate>Tuesday, 04 Aug 2026 14:56:00 +0200</pubDate>
<description>LightFTP 2.3.1 contains a residual race condition (an incomplete fix for CVE-2024-11144) in the worker_thread_cleanup() function of ftpserv.c. The control thread reads and acts on shared per-connection state, including the worker thread id it then passes to pthread_join()/pthread_cancel(), without holding the context-&gt;MTLock mutex that the worker threads use when updating that same state; and because the workers are detached, their thread id can be reused once they exit. A remote (anonymous) client triggers the window by starting a data-transfer command such as LIST and immediately issuing ABOR, running the unsynchronized cleanup while the worker is still finishing. ThreadSanitizer confirms multiple data races on the shared context and a mutex being destroyed while still in use, and the cleanup joins or cancels a detached, potentially reused thread id, which is undefined behavior that can destabilize or crash the daemon and result in denial of service. The 2.3.1 patch only narrowed the timing window (an extra re-check and reordered cleanup); it never added the missing lock, so the underlying race remains.</description>
</item>

<item>
<title>CSL 1010 M2M 3G WiFi Module 2.2.1.4 (Router.cfg) Weak XOR Encryption</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-6000</link>
<pubDate>Thursday, 30 Jul 2026 01:39:00 +0200</pubDate>
<description>The device protects its configuration file (Router.cfg) with a weak/insecure obfuscation (single-byte XOR cipher) using a static key (0xEC) instead of real encryption. Because the same key is applied to the entire file, it is trivially recovered and the configuration can be decoded back to cleartext with a few lines of code. This discloses all stored secrets in plaintext, including the web administration and telnet passwords, the WPA/WPA2 pre-shared key, PPPoE/3G/APN credentials, and SIM identifiers (IMSI/IMEI).</description>
</item>

<item>
<title>SIP Sustainable Irrigation Platform 5.x (cli_control) Remote Code Execution</title>
<link>https://www.zeroscience.mk/#/advisories/ZSL-2026-5999</link>
<pubDate>Tuesday, 14 Jul 2026 00:17:00 +0200</pubDate>
<description>SIP executes user-configured operating-system commands when an irrigation station changes state, if the optional cli_control plugin is installed and enabled. This can be exploited to run arbitrary commands on the affected host by storing a command through the plugin's HTTP endpoint and then activating the associated station. When the optional passphrase is not enabled (factory default) both steps require no authentication, and where the passphrase is enabled it defaults to 'opendoor' and the same result is reachable through cross-site request forgery.</description>
</item>

</channel>
</rss>