[Yandex Cloud documentation](../../index.md) > [Security in Yandex Cloud](../index.md) > Security bulletins
# Security bulletins
This page contains security recommendations from Yandex Cloud experts.
## June 23, 2026: Targeted data encryption attacks in the Linux infrastructure of Russian organizations {#targeted-linux-ransomware-attacks-2026}
### Original report {#original-report-linux-ransomware-2026}
* Kaspersky / Securelist. *How the Head Mare group's arsenal evolved in early 2026*: .
* F6. *Bearlyfy release the genie: F6 analyzed the group's recent attacks*: .
* Positive Technologies. *Phantom pains: Large-scale cyber-espionage campaign and possible split in the PhantomCore APT group*: .
* Sansec. *Found defunct.dat on your site? You've got a problem*: .
### Summary {#brief-description-linux-ransomware-2026}
Yandex Cloud observes targeted data encryption attacks in the Linux infrastructure of Russian organizations. The described campaign involves the APT groups Bearlyfy (Labubu, Toy Ghouls) and Head Mare (PhantomCore). The attacks mostly target application service, virtualization, and database nodes.
A typical attack chain begins with publicly available interfaces of application services, vulnerable web applications, intercepted credentials, or VPN sessions. After gaining the initial foothold, the attackers quickly perform reconnaissance, hack database credentials, and escalate the Linux node's privileges using local LPE exploits, including `CVE-2026-31431`, `CVE-2026-43284`, `CVE-2026-43500`, `CVE-2026-21533`, etc. Next, the ransomware is executed on several nodes at once in a coordinated manner.
To manage the compromised infrastructure, the attackers use a gsocket implant over public relay `gs.thc.org`, `revsocks`, reverse SSH tunnels, as well as `GOST`, `rsocx`, `cloudflared`, and `localtonet`. Consolidation is achieved through `systemd` and `cron`. Processes are disguised as Linux kernel threads using `exec -a`. The implant can remain dormant for years, so the absence of current connections to `gs.thc.org` is no guarantee that the node had not been compromised earlier.
### Timeline {#timeline-disclosure-linux-ransomware-2026}
* Latest 2023: The Head Mare group's activity is publicly attributed.
* Latest January 2025: First records of the Bearlyfy group being publicly active.
* August 2025: TrueConf Server vulnerabilities `BDU:2025-10114`, `BDU:2025-10115`, `BDU:2025-10116` used as one of the entry points are patched.
* Latest March – April 2026: Bearlyfy switches to a proprietary ransomware family called GenieLocker.
* 2026: Bearlyfy and Head Mare appear very active exchanging their tools and infrastructure.
* June 23, 2026: Yandex Cloud bulletin is published.
### Affected technologies {#technologies-affected-linux-ransomware-2026}
* Publicly available interfaces of application services: administrative APIs, automation agent interfaces, video conferencing servers, vulnerable web applications.
* Linux nodes of application services, virtualization, and databases that permit local privilege escalation after initial access.
* Hidden control and consolidation tools: `gsocket`, `revsocks`, reverse SSH tunnels, `GOST`, `rsocx`, `cloudflared`, `localtonet`, `systemd`, and `cron`.
* Ransomware: GenieLocker (`hostd`) and a variant of Babuk for Linux/ESXi.
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection-linux-ransomware-2026}
Pay attention to the following indicators of compromise:
* Connections to `gs.thc.org` and subdomains `g.gs.thc.org`, `y.gs.thc.org`, `q.gs.thc.org`, as well as to nodes `x.gs.thc.org`, `360nvidia[.]com`, `5.252.176[.]47`, `45.156.27[.]115`, and `45.87.246[.]40`.
* Files `defunct`, `hostd`, `revsocks`, `rev_socks`, `revsocks_linux_amd64`, and `fscan`, extension `.babyk`, log `/tmp/locker.log`.
* Processes named `[nm_percpu_wq]`, `[kswapd0]`, `[card0-crtc8]`, and `[slub_flushwq]`.
* Payload launched from `memfd`, strings `gsocket-engine.c`, `gsocket-ssl.c`, `_GSOCKET_INTERNAL`, `GS_connect` in binary files, cron tasks is a base64 wrapper.
* For TrueConf Server, the `the required argument for option '--Serial' is missing` string in logs.
To search for known artifacts, use these ready-made materials:
* Elastic YARA rule for `gsocket`: .
* F6 DFIR repository with GenieLocker materials: .
To reduce the risk of attack, take the following measures:
* Isolate public interfaces of application services. Administrative APIs, DBMS, automation agent interfaces, and video conferencing servers should be accessible only from a dedicated segment, not from the internet. Use security groups in [Yandex Compute Cloud](../../compute/index.md) for filtering at the VM level, and [Yandex Smart Web Security](../../smartwebsecurity/index.md) for public web frontends.
* Use trust-based segmentation for your network. Separate databases and backup storages from application segments, VPN routes, and external entry points. Use separate [Yandex Virtual Private Cloud](../../vpc/index.md) networks or subnets with security groups of their own, [Yandex Cloud Interconnect](../../interconnect/index.md) for connectivity to the corporate network, and NAT Gateway to centralize outgoing traffic.
* Disable password authentication via SSH for service accounts. Use keys, MFA, and OS Login for administrative access. This ties SSH access to Yandex Cloud accounts, allows centralized key storage, makes it impossible to use local `~/.ssh/authorized_keys` as a control point, and sends connection events to [Yandex Audit Trails](../../audit-trails/index.md).
* Move backups to immutable storage. Use [Yandex Object Storage](../../storage/index.md) with an object lock on top of a versioned bucket in Compliance mode or with permanent legal hold. Governance mode is not enough because a compromised account with the `storage.admin` role can remove this protection.
* Apply the principle of least privilege. Assign only the necessary IAM roles to service accounts, restrict access to specific buckets and operations, and avoid using excessive static keys. Store and rotate secrets in [Yandex Lockbox](../../lockbox/index.md).
* Monitor outgoing traffic from application nodes. Treat connections to non-standard ports and unknown external addresses as a high-priority signal. Keep logs to maximum available depth: due to implant stealth phase, retrospective analysis is more important than the current state. Use [Yandex Cloud Logging](../../logging/index.md) to centralize VM logs, [Yandex Audit Trails](../../audit-trails/index.md) for IAM and data plane events (including Flow and DNS logs), and [Yandex Cloud Detection and Response](../../ycdr/index.md) for network visibility.
* Scan images and artifacts for vulnerabilities in [Yandex Cloud Registry](../../cloud-registry/index.md) prior to publication. This will help reduce the build chain side risk.
* Monitor the integrity of Linux node system folders: `/etc/cron.d/`, `/var/spool/cron/`, `/lib/systemd/system/`, `~/.ssh/`, `~/.config/`. Check for substitution of legitimate `systemd` units, cron commands with `pkill -0` and `exec -a`, processes masquerading as kernel threads, accounts without any traces of creation or interactive logins, and year-long gaps between `mtime` and `Birth time`.
* Use YARA rules to scan the file system and memory. Memory checks are especially important because `gsocket` can be executed from `memfd` without the file on the disk.
* If you detect a compromise, do not reboot or shut down the node before you take snapshots of the system disk and user disks, and if possible also a memory dump, with the help of [Yandex Compute Cloud](../../compute/index.md). Isolate the node via security groups without disconnecting the network interface, contact Yandex Cloud support, and rotate all credentials available to the compromised node. Pre-configured scheduled snapshots and [Yandex Cloud Backup](../../backup/index.md) make recovery simpler.
* Use built-in Yandex Cloud tools. With [Yandex Identity Hub](../../organization/index.md) and an identity federation, you can centralize administrative access with session lifetime of up to six hours. [Yandex Security Deck](../../security-deck/index.md) helps you identify excessive permissions, infrastructure and Kubernetes cluster configuration errors, and open secrets. [Yandex Cloud Detection and Response](../../ycdr/index.md) helps you detect malicious network activities and monitor changes in IAM, while keeping audit data outside the customer's perimeter.
## 06/05/2026: CVE-2026-49975 HTTP/2 Bomb: Remote denial of service in HTTP/2 implementations {#CVE-2026-49975}
CVE ID: CVE-2026-49975
Additional ID: CVE-2026-47774: Vulnerability in Envoy.
CVE link:
At the time of publication, the NIST NVD card for CVE-2026-49975 has not been publicly created. The CVE was assigned by a CNA; the record on cve.org is in the _Reserved_ status and will be updated after data publication.
### Original report {#original-report-CVE-2026-49975}
* Codex Discovered a Hidden HTTP/2 Bomb:
* PoC and research materials:
* NGINX patch, `max_headers` directive:
* NGINX guides on `max_headers`:
* Apache httpd patch, `mod_http2` v2.0.41:
* Apache `mod_h2` releases:
* Envoy Security Advisory GHSA-22m2-hvr2-xqc8 / CVE-2026-47774:
* RFC 7541 (HPACK):
* RFC 9113 (HTTP/2):
### Summary {#brief-description-CVE-2026-49975}
Researchers at Calif have discovered a denial of service vulnerability in the processing of HTTP/2 requests by several popular web servers and proxies. This attack was named HTTP/2 Bomb.
The vulnerability is related to specific aspects of HTTP/2 HPACK and _flow control_ processing. An attacker can send compactly encoded HTTP/2 headers that, when decoded, cause significant memory consumption growth on the server side. The _flow control_ mechanism can then be used to keep streams open and pin the allocated memory.
Successful exploit may lead to process memory exhaustion, worker process crashes, or denial of service of the HTTP/2 endpoint. No authentication is required for exploit.
The vulnerability only affects service availability. At the time of publication, there is no evidence of user data disclosure or modification via this vulnerability.
### Affected technologies {#technologies-affected-CVE-2026-49975}
The issue is relevant for systems that accept HTTP/2 traffic directly and use vulnerable versions of web servers, reverse proxies, or HTTP/2 terminators.
Implementations confirmed in the original report:
* nginx
* Apache httpd / `mod_http2`
* Microsoft IIS
* Envoy
* Cloudflare Pingora
HTTP/1.1-only endpoints are not susceptible to the described HTTP/2 Bomb attack chain.
### Vulnerable products and versions {#vulnerable-products-and-versions-CVE-2026-49975}
#|
|| **Product** | **Vulnerable versions / Status** | **Fixing** ||
|| nginx | Versions below 1.29.8 with HTTP/2 enabled. Exploitat confirmed on nginx 1.29.7. | Update to nginx 1.29.8 or newer. Version 1.29.8 adds the `max_headers` directive with a default value of `1000`. ||
|| NGINX Plus | Versions based on nginx Open Source below 1.29.8 with HTTP/2 enabled. | Use an NGINX Plus version that includes the `max_headers` fix, e.g., NGINX Plus PLS 37.0.0.1 LTS or newer. ||
|| Apache httpd / `mod_http2` | Versions with `mod_http2` below 2.0.41. Exploit was confirmed on Apache httpd 2.4.67 in the report. | Update `mod_http2` to 2.0.41 or newer. Check for the fix in your distribution packages or vendor-built Apache httpd. ||
|| Envoy | Versions prior to the fixed branches 1.35.11, 1.36.7, 1.37.3, and 1.38.1. A separate advisory GHSA-22m2-hvr2-xqc8 and CVE-2026-47774 were published for Envoy. | Update Envoy to 1.35.11, 1.36.7, 1.37.3, 1.38.1, or a newer fixed version. ||
|| Microsoft IIS | The vulnerability was confirmed for Microsoft IIS on Windows Server 2025. At the time of preparing this bulletin, no public fix was confirmed in the original report. | Stay tuned for Microsoft updates. Until a fix is released, disable HTTP/2 or restrict direct access to IIS behind a secured L7 load balancer. ||
|| Cloudflare Pingora | The vulnerability was confirmed for Pingora 0.8.0. At the time of preparing this bulletin, no public fix was confirmed in the original report. | Stay tuned for Pingora/Cloudflare updates. Until a fix is released, disable HTTP/2 or use an external L7 terminator with restrictions on HTTP/2 headers. ||
|#
### Developer {#vendor-CVE-2026-49975}
The vulnerability affects several independent web server and proxy vendors (see the table above). Patches for nginx, Apache `mod_http2`, and Envoy have already been released. For Microsoft IIS and Cloudflare Pingora, public fixes are not available at the time of this bulletin’s publication.
### Attack vector and severity level as per CVSS v.3.1 {#attack-vector-and-severity-level-CVE-2026-49975}
For CVE-2026-49975, a CVSS base score from NIST NVD is not yet available at the time of publication.
By its impact, the vulnerability belongs to the remote denial of service class:
* Attack vector: network
* Attack complexity: low
* Privileges required: not required
* User interaction: not required
* Confidentiality impact: none
* Integrity impact: none
* Availability impact: high
For the related Envoy vulnerability CVE-2026-47774, the GitHub Security Advisory indicates a score of 7.5 HIGH with the vector:
```text
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
```
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection-CVE-2026-49975}
Check whether your public services accept HTTP/2 traffic directly on vulnerable components.
For NGINX:
```bash
nginx -v
nginx -T | grep -Ei 'http2|max_headers|listen .*443'
```
For Apache httpd:
```bash
apachectl -M | grep -i http2
httpd -v
```
For Envoy:
```bash
envoy --version
```
We also recommend to test public endpoints for HTTP/2 support via ALPN and ensure that backend services are not directly accessible bypassing the load balancer.
Signs of possible exploit:
* A sharp increase in memory consumption by _web server_ or _reverse proxy_ processes.
* OOM kills of worker processes.
* A large number of long-lived HTTP/2 streams.
* An unusual number of HTTP/2 requests with many _cookies_ or _header_ fragments.
* An increase in 5xx errors or endpoint unavailability without a corresponding increase in legitimate load.
### Safe version of vulnerable product or patch {#safe-version-CVE-2026-49975}
Update vulnerable components to the following versions or newer:
* nginx: 1.29.8 or higher
* NGINX Plus: a version that includes the fix from nginx Open Source 1.29.8, e.g., NGINX Plus PLS-37.0.0.1 LTS and higher.
* Apache `mod_http2`: 2.0.41 or higher.
* Envoy: 1.35.11, 1.36.7, 1.37.3, 1.38.1, or a newer fixed version.
* Microsoft IIS: install the Microsoft fix after its release; until then, apply temporary measures.
* Cloudflare Pingora: install the vendor fix after its release; until then, apply temporary measures.
#### Mitigations
If an immediate update is not possible, apply temporary risk reduction measures.
**1. Use managed Yandex Cloud load balancers**
For public HTTP/HTTPS services, we recommended to use [Yandex Application Load Balancer](../../application-load-balancer/index.md) as a single public entry point.
Recommended architecture:
```text
Internet
-> Yandex Application Load Balancer
-> private backend group
```
Backend services should not be directly accessible from the internet. Configure security groups so that incoming traffic to backend instances or pods is allowed only from the load balancer and trusted internal networks.
For HTTP/HTTPS traffic, it is better to use an L7 load balancer. L4 load balancing without HTTP/2 termination does not eliminate the risk if a vulnerable HTTP/2 terminator remains accessible on the backend.
**2. Disable HTTP/2 on vulnerable public endpoints**
If an update is not yet possible, temporarily disable HTTP/2.
For NGINX:
```nginx
server {
listen 443 ssl;
http2 off;
}
```
In configurations where HTTP/2 is enabled via the `listen` parameter, remove the `http2` parameter:
```nginx
listen 443 ssl;
```
For Apache httpd:
```apache
Protocols http/1.1
```
For Envoy, temporarily disable downstream HTTP/2 on public listeners if it is compatible with your service.
For IIS, disable HTTP/2 according to Microsoft guides, or restrict direct access to IIS behind an L7 load balancer that terminates HTTP/2 and applies limits.
**3. Limit HTTP/2 headers and cookies**
Configure strict limits:
* Maximum number of HTTP headers.
* Maximum decoded size of headers (not just the encoded HPACK size).
* Maximum cookie size.
* Maximum number of cookie fragments.
* Maximum number of concurrent HTTP/2 streams per connection.
* Maximum lifetime of a stream/request.
* Idle/read/send timeouts for HTTP/2 connections.
For nginx 1.29.8 or higher, use the `max_headers` directive:
```nginx
max_headers 1000;
```
For Apache httpd, note that `LimitRequestFieldSize` may only be a partial measure, and `LimitRequestFields` does not fully cover the described scenario for vulnerable versions of `mod_http2`. The priority measure is to update `mod_http2` to a fixed version.
**4. Limit the consequences of memory exhaustion**
As an additional protection, configure resource limits for processes and containers:
* cgroups or container memory limits.
* `MemoryMax` in systemd.
* Kubernetes resource limits.
* `ulimit`.
* Automatic restart policy for worker processes.
These measures do not fix the vulnerability but help contain the blast radius during an exploit attempt.
**5. Close direct access to the backend**
Ensure that backend services running on nginx, Apache httpd, Envoy, IIS, or Pingora are not published directly to the internet bypassing the load balancer.
It is especially important to check:
* Public IPv4/IPv6 addresses of virtual machines.
* NodePort/LoadBalancer services in Kubernetes.
* Ingress controllers.
* debug/staging endpoints.
* Temporary NAT or firewall rules.
For Yandex Managed Service for Kubernetes:
* For clusters with public addresses, restrict access to the cluster API (ports 443 and 6443) with specific required prefixes.
* For all clusters (with both public and private master addresses), ensure that the [cluster security group](../../managed-kubernetes/operations/connect/security-groups.md) contains a rule allowing traffic from the source "Load balancer health checks" to ports 7890 and 7891.
* For all clusters, ensure that the cluster security group does not contain rules allowing traffic to ports 7890 and 7891 from other sources.
### Disclosure timeline {#timeline-disclosure-CVE-2026-49975}
* April 2026: vulnerability disclosed to nginx developers; fix added in nginx 1.29.8.
* May 27, 2026: vulnerability disclosed to Apache; fix committed to `mod_http2` 2.0.41.
* June 2, 2026: original report published by Calif: "Codex Discovered a Hidden HTTP/2 Bomb".
* June 3, 2026: Envoy advisory GHSA-22m2-hvr2-xqc8 / CVE-2026-47774 and fixed Envoy versions published.
* June 5, 2026: Yandex Cloud bulletin published.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services-CVE-2026-49975}
Yandex Cloud services are being updated to prevent exploit of the vulnerability. The vulnerability does not affect the confidentiality or integrity of user data.
User deployed services on virtual machines, containers, in Yandex Managed Service for Kubernetes, or custom images must be reviewed by the owners of those services.
We recommend users to:
* Use Yandex Application Load Balancer for public HTTP/HTTPS endpoints.
* Block direct internet access to backend services.
* Update nginx, Apache httpd / `mod_http2`, Envoy, IIS, or Pingora to fixed versions.
* Apply temporary mitigations if an update is not immediately possible.
* Ensure HTTP/2 is not enabled on vulnerable public endpoints unless necessary.
## 08/05/2026 – CVE-2026-43284 / CVE-2026-43500 Dirty Frag and Copy Fail 2 – Local privilege escalation to root in Linux kernel via the xfrm-ESP and RxRPC subsystems {#CVE-2026-43284}
CVE IDs: CVE-2026-43284, CVE-2026-43500
CVE link:
### Original report {#original-report-CVE-2026-43284}
* Dirty Frag (PoC and write-up):
* Copy Fail 2: Electric Boogaloo (PoC xfrm-ESP):
* oss-security newsletter:
### Summary {#brief-description-CVE-2026-43284}
Dirty Frag is a class of logical vulnerabilities in the Linux kernel that allows an unprivileged local user to get superuser (`root`) permissions. The exploit combines two independent page-cache write primitives in the xfrm-ESP and RxRPC subsystems. Each primitive is self-sufficient to escalate privileges.
The attack:
* Requires no remote access, just an unprivileged local account.
* Is a deterministic logical bug without a race condition which succeeds on first attempt.
* Does not cause kernel panic in case of failure to exploit.
* Can be used as a container-to-host escape primitive because the page cache is shared across the entire node.
The root cause of both variants is the same: when using `splice()` / `MSG_SPLICE_PAGES`, the kernel puts page cache pages directly into socket buffer fragments (`skb`). The xfrm-ESP and RxRPC subsystems perform in-place decryption on such fragments without checking them for privacy. As a result, the attacker gets a controlled record in the page cache of any file they want to read, e.g., `/usr/bin/su` or `/etc/passwd`.
Copy Fail 2: Electric Boogaloo is an independent PoC that exploits the same xfrm-ESP primitive (CVE-2026-43284). It has the same vulnerability class as Copy Fail (CVE-2026-31431) but affects another kernel subsystem.
### Affected technologies {#technologies-affected-CVE-2026-43284}
* Linux kernel, `net/ipv4/esp4.c` /`net/ipv6/esp6.c` subsystem (xfrm-ESP).
* Linux kernel, `net/rxrpc/rxkad.c` subsystem (RxRPC/RxKAD).
* `splice()` / `vmsplice()` system calls in conjunction with UDP sockets (ESP-in-UDP encapsulation) and `AF_RXRPC`.
The vulnerability does not directly affect `AF_ALG` (`algif_aead` is a separate Copy Fail vulnerability, CVE-2026-31431), dm-crypt / LUKS, kTLS, in-kernel TLS, or IPsec in tunnel mode without UDP encapsulation.
### Vulnerable products and versions {#vulnerable-products-and-versions-CVE-2026-43284}
Linux kernel:
* xfrm-ESP variant (CVE-2026-43284): Kernels starting from commit `cac2661c53f3` (January 2017) until the bugfix patch date (around nine years of presence in the mainline).
* RxRPC variant (CVE-2026-43500): Kernels starting from commit `2dc334f1a63a` (June 2023) until the present date (there is no patch yet).
The exploit was confirmed on: Ubuntu 24.04 LTS (6.8.0-110), Ubuntu 26.04 LTS (7.0.0-15), Debian 13 (6.12.74), Arch (6.19.11), Fedora 43/44, RHEL 10.1, CentOS Stream 10, AlmaLinux 10, openSUSE Tumbleweed.
Ubuntu 22.04 LTS (5.15.0-176) is not vulnerable to the xfrm-ESP variant.
### Developer {#vendor-CVE-2026-43284}
Linux kernel community (mainline). The patch for xfrm-ESP was merged into the mainline on 08/05/2026. As of the time of the publication, there is no patch for the RxRPC component.
### Attack vector and severity level as per CVSS v.3.1 {#attack-vector-and-severity-level-CVE-2026-43284}
As of the time of the publication, no base score has been assigned. The bulletin will be updated after the score is published in NVD.
The vulnerability is similar in nature to Copy Fail (CVE-2026-31431, 7,8 HIGH, `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`): it is a local privilege escalation without a race condition.
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection-CVE-2026-43284}
* Disable the vulnerable modules as quickly as possible before you install the kernel patch. The command below must be run as `root` effective immediately:
```bash
# printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
# rmmod esp4 esp6 rxrpc 2>/dev/null || true
```
* Blocking the `esp4`/`esp6` modules will disrupt IPsec VPN. For systems using IPsec, updating the kernel is a priority measure.
* Once mitigation is applied, it makes sense to reset the page cache to prevent exploitation of potentially modified pages:
```bash
# echo 3 > /proc/sys/vm/drop_caches
```
* Update the kernel to a version with an xfrm-ESP patch. The fix was merged into the mainline on 08/05/2026 (commit `f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4`). The patch sets the `SKBFL_SHARED_FRAG` flag for fragments received via `splice()` and forces `esp_input()` / `esp6_input()` to perform copy-on-write via `skb_cow_data()` for such fragments.
* As of the time of the publication, there is no patch for the RxRPC component (CVE-2026-43500). The only available mitigation is to block the `rxrpc` module loading.
* For containerized and sandboxed workloads, it makes sense to restrict XFRM operations and creation of `AF_RXRPC` sockets via seccomp irrespective of the status of patches.
### Safe version of vulnerable product or patch {#safe-version-CVE-2026-43284}
xfrm-ESP (CVE-2026-43284): The vulnerability was fixed in mainline commit `f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4` on 08/05/2026. Backports to stable branches (commits `50ed1e787310`, `52646cbd00e7`, `71a1d9d985d2`, and `b54edf1e9a3f` as per NVD) are currently being prepared for inclusion into distribution updates.
RxRPC (CVE-2026-43500): There is no patch. The only available mitigation is to block the `rxrpc` module.
### Disclosure timeline {#disclosure-timeline-CVE-2026-43284}
* 30/04/2026 – Report sent to Linux kernel security team (`security@kernel.org`).
* 30/04/2026 – Patch published in the netdev newsletter.
* 04/05/2026 – Kuan-Ting Chen offers an alternative patch with the shared-frag flag.
* 07/05/2026 – Patch merged into the netdev tree. The embargo violated by a third party. The RxRPC exploit publicly disclosed.
* 07/05/2026 – Full Dirty Drag document published on oss-security.
* 08/05/2026 – Patch merged into the Linux mainline. Reference ID CVE-2026-43284 assigned.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services-CVE-2026-43284}
Yandex Cloud infrastructure configurations were updated ahead of the mitigation measures.
Managed Service for Kubernetes users should apply a mitigation measure on their cluster nodes. For this purpose, the [previously published DaemonSet was updated](https://github.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation), which disables the `esp4`, `esp6`, and `rxrpc` modules in addition to `algif_aead` to mitigate the [previous Copy Fail vulnerability](#CVE-2026-31431). Run this command to apply it:
```bash
$ kubectl apply -f copy-fail-mitigation-daemonset.yaml
```
Relevant image versions with the mitigation measures packed in are being prepared for publication on Yandex Cloud Marketplace.
Once they are released, this bulletin will get an update to provide further instructions.
## 30/04/2026 – CVE-2026-31431 Copy Fail – Local privilege escalation to root in Linux kernel via the AF_ALG subsystem {#CVE-2026-31431}
CVE ID: CVE-2026-31431
CVE link:
### Original report {#original-report}
* Vulnerability website:
* Technical analysis by Xint Code (Theori):
* PoC and issue tracker:
### Summary {#brief-description}
Copy Fail (CVE-2026-31431) is a logical vulnerability in the cryptographic API subsystem of the Linux kernel allowing a regular user to get superuser permissions (`root`). PoC runs in all major Linux distributions issued since 2017 up to the patch release date, without any kernel-specific or distribution-specific modifications.
The attack:
* Requires no remote access, just an unprivileged local account.
* Requires neither race window, nor kernel-specific offsets.
* Uses the kernel’s cryptographic API (`AF_ALG`) featured in standard configurations of nearly all mainstream distributions.
* Can be used as a container-to-host escape primitive because the page cache is shared across the entire node.
### Affected technologies {#technologies-affected}
* Linux kernel, `crypto/` subsystem (`algif_aead` module).
* `AF_ALG` user-space interface.
* `splice()` system call in conjunction with `AF_ALG` sockets.
This vulnerability does not directly affect the following cryptographic API use scenarios: dm-crypt/LUKS, kTLS, IPsec/XFRM, in-kernel TLS, OpenSSL/GnuTLS/NSS in standard builds, SSH, kernel keyring crypto – all of these work with the in-kernel crypto API directly bypassing `AF_ALG`.
### Vulnerable products and versions {#vulnerable-products-and-versions}
The vulnerable Linux kernels are those built during the period from 2017 (when the `algif_aead` in-place optimization was introduced) to the bugfix patch date. The module being part of the default kernel configuration of most distributions, "out-of-the-box" exploitation is possible.
### Developer {#vendor}
Linux kernel community (mainline). The vulnerability was introduced by a 2017 commit implementing in-place optimization in `algif_aead`. The bugfix patch was merged into the mainline.
### Attack vector and severity level as per CVSS v.3.1 {#attack-vector-and-severity-level}
Base score: 7,8 HIGH
Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
* Disable `algif_aead` as quickly as possible before you install the kernel patch. The command below is executed by `root` and applies immediately (new `AF_ALG` sockets cannot be created; those opened earlier will continue to operate until closed):
```bash
# echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
# rmmod algif_aead 2>/dev/null || true
```
* Update the kernel to a patched version. The vulnerability is present in 4.14 kernels (commit `72548b093ee3`, 2017) and was fixed in the following releases:
* 6.18.22 (stable branch): commit `fafe0fa2995a`
* 6.19.12 (stable br:ch): commit `ce42ee423e58`
* 7.0-rc7 (mainline): commit `a664bf3d603d`
* For containerized and sandboxed workloads, it makes sense to block creation of `AF_ALG` sockets via seccomp, no matter the status of patches.
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability fixed in versions 6.18.22, 6.19.12, and 7.0-rc7 (mainline commit `a664bf3d603d`).
### Disclosure timeline {#timeline-disclosure}
* 23/03/2026: Report sent to Linux kernel security team.
* 24/03/2026: Initial acknowledgment of receipt of the report.
* 25/03/2026: Patches proposed and reviewed in the mailing list.
* 01/04/2026: Patch merged into the mainline.
* 22/04/2026: ID CVE-2026-31431 assigned.
* 29/04/2026: Public disclosure at .
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
Yandex Cloud infrastructure configurations were updated to implement mitigation measures.
To address the vulnerability immediately, Managed Service for Kubernetes users should go ahead with a mitigation measure on their cluster nodes. For this purpose, a [DaemonSet was published](https://github.com/yandex-cloud-examples/yc-mk8s-copy-fail-mitigation) which disables the `algif_aead` module. In subsquent revisions, the vulnerability will be automatically fixed for all supported versions.
To apply the changes:
```bash
$ kubectl apply -f copy-fail-mitigation-daemonset.yaml
```
Relevant image versions with mitigation measures in place are currently being prepared for release on Yandex Cloud Marketplace.
Once they are released, this bulletin will be updated with further instructions.
## 25/12/2025: CVE-2025-14847 (MongoBleed) Reading uninitialized memory in zlib {#CVE-2025-14847}
CVE ID: CVE-2025-14847
CVE link:
### Original report {#original-report}
### Summary {#brief-description}
The MongoDB Server’s zlib implementation has a vulnerability which an external client can exploit by tricking the server to return uninitialized heap memory. During zlib decompression, MongoDB may use the length of the allocated buffer rather than the actual length of decompressed data.
Therefore, the server treats the entire buffer as valid data, including the uninitialized part. Thus, by artificially inflating `uncompressedSize`, an attacker can gain access to out-of-scope data. This vulnerability may be exploited remotely and without authentication, which means sensitive data may get leaked.
### Compromised technologies {#technologies-affected}
Yandex StoreDoc
### Vulnerable products and versions {#vulnerable-products-and-versions}
MongoDB:
* 8.2.0 — 8.2.2
* 8.0.0 — 8.0.16
* 7.0.0 — 7.0.26 (in advisory; fixed in 7.0.28)
* 6.0.0 — 6.0.26
* 5.0.0 — 5.0.31
* 4.4.0 — 4.4.29
* all versions of branches 4.2, 4.0, 3.6
### Developer {#vendor}
MongoDB, Inc.
### Attack vector and severity level as per CVSS v.3.0 {#attack-vector-and-severity-level}
Base score: 7.5 HIGH
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
* Upgrade immediately to one of these versions: 8.2.3 / 8.0.17 / 7.0.28 / 6.0.27 / 5.0.32 / 4.4.30 (or higher).
* If upgrading is not possible, use this workaround: disable zlib compression on `mongod/mongos` by specifying `networkMessageCompressors` or `net.compression.compressors` without `zlib`, e.g., `snappy,zstd` or `disabled`.
### Safe version of vulnerable product or patch {#safe-version}
The vulnerability has been fixed in the following versions:
* 8.2.3
* 8.0.17
* 7.0.28
* 6.0.27
* 5.0.32
* 4.4.30
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
Zlib compression was disabled and DBMS processes were restarted on Yandex StoreDoc cluster hosts with public addresses between 01:00 and 03:00 Moscow time. If you encounter any issues, contact support.
## 02/04/2025: CVE-2025-1385 Remote code execution in ClickHouse Library Bridge {#CVE-2025-1385}
CVE ID: CVE-2025-1385
CVE link:
### Original report {#original-report}
### Summary {#brief-description}
A vulnerability in ClickHouse made it possible to run code remotely with the Library Bridge feature enabled. The `clickhouse-library-bridge` feature exposed an HTTP API on `localhost`, allowing `clickhouse-server` to dynamically load libraries from specific paths and run them in an isolated process. If used together with the ClickHouse table engine which allows file uploads to certain directories, servers with misconfigured settings could be exploited by attackers if they had access to table engines allowing them to run any code on the ClickHouse server.
### Compromised technologies {#technologies-affected}
ClickHouse
### Vulnerable products and versions {#vulnerable-products-and-versions}
* ClickHouse below version 24.3.18.6
* ClickHouse below version 24.8.14.27
* ClickHouse below version 24.11.5.34
* ClickHouse below version 24.12.5.65
* ClickHouse below version 25.1.5.5
### Developer {#vendor}
ClickHouse, Inc.
### Attack vector and severity level as per CVSS v.3.0 {#attack-vector-and-severity-level}
Not assigned.
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
To check if you ClickHouse server is vulnerable, check the configuration file and make sure the following setting is enabled:
```
9019
```
### Safe version of vulnerable product or patch {#safe-version}
The vulnerability has been fixed in the following versions:
* 24.3.18.6
* 24.8.14.27
* 24.11.5.34
* 24.12.5.65
* 25.1.5.5
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
Yandex Managed Service for ClickHouse® is updated to versions with the vulnerability fixed. No user action is required.
When using ClickHouse on your own VMs in Yandex Cloud, no additional end user actions are required, as the vulnerability is already fixed in the new image versions.
## 01/04/2024: CVE-2025-1974 Vulnerability in ingress-nginx in Kubernetes {#CVE-2025-1974}
CVE ID: CVE-2025-1974
CVE link:
### Original report {#original-report}
### Summary {#brief-description}
A Kubernetes vulnerability was discovered allowing an intruder who has not passed authentication and has access to the pod network to run any code in the ingress-nginx controller context. This may unlock unauthorized access to secrets available to the controller. By default, the controller can access all secrets in the cluster.
### Compromised technologies {#technologies-affected}
Kubernetes
### Vulnerable products and versions {#vulnerable-products-and-versions}
* Versions through 1.11.4
* Version 1.12.0
### Attack vector and severity level as per CVSS v.3.0 {#severity-level}
9,8 CRITICAL.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations}
To check whether or not you have ingress-nginx installed in your cluster, run this command: `kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx`.
### Safe version of vulnerable product or patch {#safe-version}
If you are using an ingress-nginx version from Cloud Marketplace, the upgrade is available only for Kubernetes versions 1.28 or higher.
You cannot install a safe ingress-nginx version in clusters with Kubernetes versions prior to 1.28 unless you upgrade the Kubernetes version first.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
{% note alert %}
NGINX Ingress controller support ends in March 2026. For more information, see [Ingress NGINX Retirement: What You Need to Know](https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/).
We recommend [migrating](../../managed-kubernetes/alb-ref/nginx-gwin-migration.md) to the new [Yandex Cloud Gwin](../../managed-kubernetes/alb-ref/gwin-index.md) controller.
{% endnote %}
We recommend installing the safe ingress-nginx version:
* Helm: Reinstall ingress-nginx with this option on: `--set controller.admissionWebhooks.enabled=false`.
* YAML manifest:
1. Delete the `ValidatingWebhookConfiguration` resource named `ingress-nginx-admission`.
1. Edit the `Deployment` or `Daemonset` resources named `ingress-nginx-controller` by deleting the `--validating-webhook` key from the list of arguments.
## 06/03/2024: CVE-2024-21626: runc process.cwd and leaked fds container breakout {#CVE-2024-21626}
CVE ID: CVE-2024-21626
CVE link:
### Original report {#original-report}
### Summary {#brief-description}
runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from `runc exec`) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem («attack 2»). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through `runc run` «attack 1»). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes («attack 3a» and «attack 3b»).
runc 1.1.12 includes patches for this issue.
### Technologies affected {#technologies-affected}
runc
### Vulnerable products and versions {#vulnerable-products-and-versions}
From v1.0.0 before v1.1.11
### Attack vector and severity level per CVSS v.3.0 {#severity-level}
7.5 High
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations}
Public exploits:
*
*
### Safe version of vulnerable product or patch {#safe-version}
The vulnerability has been fixed as of version 1.1.12.
### Are cloud services affected? {#impact-on-yandex-cloud-services}
We updated current and upcoming images that use `runc` to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 05/07/2024: CVE-2024-6387 RegreSSHion {#CVE-2024-6387}
CVE ID: CVE-2024-6387
CVE link:
### Original report {#original-report}
### Summary {#brief-description}
The vulnerability lies in the race condition that appears on the OpenSSH server (sshd), which sometimes enables running remote code without authentication (RCE) under the `root` username in `glibc`-based Linux systems. This poses a significant threat to security. It takes at least six hours for the attacker to exploit this issue.
### Technologies affected
`openssh-server`
### Vulnerable products and versions {#vulnerable-products-and-versions}
* `openssh-server` before `4.4p1`
* `openssh-server` from `8.5p1` to `9.8p1`
### Vendor {#vendor}
OpenBSD Project
### Attack vector and severity level as per CVSS v.3.0 {#attack-vector-and-severity-level}
Base score: 8.1 HIGH
Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
As a workaround, set `LoginGraceTime` to `0` in `/etc/ssh/sshd_config`. This will prevent the exploit, although will potentially allow DDoS attacks on the server.
See also:
### Safe version of vulnerable product or patch {#safe-version}
Learn which `openssh-server` version you are currently using by running the `dpkg -l openssh-server` command. If your version is vulnerable, update your package to `9.8p1` or higher.
### How it impacts Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated VM basic images to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
We checked for the presence of vulnerable internal Yandex Cloud services.
## 06/03/2024: CVE-2023-23919: Multiple OpenSSL error handling issues in nodejs crypto library {#CVE-2023-23919}
CVE ID: CVE-2023-23919
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
A cryptographic vulnerability exists in Node.js <19.2.0, <18.14.1, <16.19.1, <14.21.3 that in some cases did does not clear the OpenSSL error stack after operations that may set it. This may lead to false positive errors during subsequent cryptographic operations that happen to be on the same thread. This in turn could be used to cause a denial of service.
### Technologies affected {#technologies-affected}
Node.js. Affects OpenSSL
### Vulnerable products and versions {#vulnerable-products-and-versions}
Node.js <= ver. 19.2.0, 18.14.1, 16.19.1, 14.21.3
### Vendor {#vendor}
OpenJS Foundation
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Base Score: 7.5
HIGHVector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
*
*
*
*
### Safe version of vulnerable product or patch {#safe-version}
Recent releases Node.js and OpenSSL already contain fixes for this error.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We have compiled and implemented an up-to-date Node.js in the images. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 06/03/2024: CVE-2023-23946: GitLab Critical Security Release: 15.8.2, 15.7.7 and 15.6.8 {#CVE-2023-23946}
CVE ID: CVE-2023-23946
Link to CVE:
### Original report {#original-report}
*
*
*
### Summary {#brief-description}
Multiple vulnerabilities. The full list:
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
GitLab CE/EE < 15.8.2, 15.7.7, and 15.6.8
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Base Score: 6.2.
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerabilities have been fixed in versions 115.8.2, 15.7.7 and 15.6.8
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
For the convenience of users of the Yandex Managed Service for GitLab, we have already updated existing and future instances to the latest version. If you are using an image on a VM, it is recommended that you update it yourself.
## 06/03/2024: CVE-CVE-2023-22490: GitLab Critical Security Release: 15.8.2, 15.7.7 and 15.6.8 {#CVE-CVE-2023-22490}
CVE ID: CVE-CVE-2023-22490
Link to CVE:
### Original report {#original-report}
*
*
*
### Summary {#brief-description}
Multiple vulnerabilities. The full list:
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
GitLab CE/EE < 15.8.2, 15.7.7, and 15.6.8
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVE-2023-22490
Base Score: 5.5. CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerabilities have been fixed in versions 115.8.2, 15.7.7 and 15.6.8
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
For the convenience of users of the Yandex Managed Service for GitLab, we have already updated existing and future instances to the latest version. If you are using an image on a VM, it is recommended that you update it yourself.
## 28/12/2023: CVE-2023-44487 HTTP/2 Rapid Reset DDoS Attack {#CVE-2023-44487}
CVE ID: CVE-2023-44487
CVE link:
### Original report {#original-report}
### Summary {#brief-description}
Yandex Cloud has implemented all necessary measures against CVE-2023-44487 known as _HTTP/2 Rapid Reset_.
This vulnerability is related to the HTTP/2 protocol. Under certain conditions, can be exploited to execute a denial-of-service attack on webservers such as NGINX, envoy and other products that implement the server-side portion of the HTTP/2 specification. To protect your systems from this attack, we’re recommending an immediate update to your web server.
### Technologies affected {#technologies-affected}
NGINX, HTTP/2
### Vulnerable products and versions {#vulnerable-products-and-versions}
* NGINX Open Source 1.x: 1.25.2 - 1.9.5
* org.apache.tomcat.embed:tomcat-embed-core package, versions [,8.5.94], [9.0.0,9.0.81], [10.0.0,10.1.14], [11.0.0-M3,11.0.0-M12]
* NGINX Ingress Controller
* 3.x 3.0.0 - 3.3.0 3.3.1
* 2.x 2.0.0 - 2.4.2
* 1.x 1.12.2 - 1.12.5
* Envoy 1.27.1, 1.26.5, 1.25.10 or 1.24.10
* NGINX Plus R2x R25 - R30
* BIG-IP (all modules) 17.x 17.1.0
* BIG-IP Next (all modules) 20.x 20.0.1
* BIG-IP Next SPK 1.x 1.5.0 - 1.8.2
*
### Base vector and severity level of the vulnerability according to CVSS v.3.0 {#severity-level}
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
### Recommendations for vulnerability detection and additional materials {#recommendations-for-vulnerability-detection}
Procedure for checking the vulnerability and supporting materials (PoC code, video demonstration or others):
Update or patch version:
* Upgrade org.apache.tomcat.embed:tomcat-embed-core to version 8.5.94, 9.0.81, 10.1.14, 11.0.0-M12 or higher.
* Upgrade envoyproxy/envoy to version 1.24.11, 1.25.10, 1.26.5, 1.27.1 or higher.
* Use http2_max_concurrent_streams directive NGINX
* Use [Yandex Smart Web Security](https://yandex.cloud/en/services/smartwebsecurity)
### Safe version of vulnerable product or patch {#safe-version}
Not yet.
### Are cloud services affected? {#impact-on-yandex-cloud-services}
No.
## 28/12/2023: CVE-2023-23583 Reptar vulnerability in Ice Lake (IPU Out-of-Band) {#CVE-2023-23583}
CVE ID: CVE-2023-23583
CVE link:
### Summary {#brief-description}
The Reptar vulnerability affects Intel-based server systems, and the manufacturer has released the necessary patches. The Yandex Cloud infrastructure has been updated.
The vulnerability potentially led to privilege escalation.
### Technologies affected {#technologies-affected}
Intel (microcode)
### Vulnerable products and versions {#vulnerable-products-and-versions}
### Base vector and severity level of the vulnerability according to CVSS v.3.0 {#severity-level}
7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
### Recommendations for vulnerability detection and additional materials {#recommendations-for-vulnerability-detection}
Procedure for checking the vulnerability and supporting materials (PoC code, video demonstration or others):
Update or patch version:
### Safe version of vulnerable product or patch {#safe-version}
The vulnerability has been fixed as of version 1.9.0.
### Are cloud services affected? {#impact-on-yandex-cloud-services}
No.
## 28/12/2023: CVE-2023-46850 OpenVPN v.2.6.7 Security patch {#CVE-2023-46850}
CVE IDs: CVE-2023-46849, CVE-2023-46850
CVE link:
### Original report {#original-report}
### Summary {#brief-description}
CVE-2023-46850: it can lead to sending the contents of the process memory to the other side of the connection, as well as potentially to remote code execution.
CVE-2023-46849: this may lead to the remote initiation of an emergency shutdown of the access server.
### Technologies affected {#technologies-affected}
OpenVPN
### Vulnerable products and versions {#vulnerable-products-and-versions}
From v2.6.0 before v2.6.6
### Base vector and severity level of the vulnerability according to CVSS v.3.0 {#severity-level}
Network.
### Procedure for checking the vulnerability and supporting materials (PoC code, video demonstration or others) {#poc}
No PoC yet.
### Safe version of vulnerable product or patch {#safe-version}
The vulnerability has been fixed as of version 2.6.7.
### Are cloud services affected? {#impact-on-yandex-cloud-services}
Yes.
## 3/11/2023: CVE-2023-5043 NGINX Ingress Controller for Kubernetes vulnerabilities {#CVE-2023-5043}
CVE IDs: CVE-2023-5043, CVE-2023-5044, CVE-2022-4886
CVE links:
### Original report {#original-report}
### Summary {#brief-description}
The first two vulnerabilities, CVE-2023-5043 and CVE-2023-5044, are related to insufficiently checking input data, which may lead to adding malicious code, taking control of privileged credentials, and stealing all cluster's secrets. Both issues have 7.60/10 vulnerability score as per the CVSS.
The CVE-2022-4886 vulnerability has higher score, 8.80 as per the CVSS. This issue can be exploited when creating or updating Ingress objects. The attackers may get access to the Kubernetes API credentials from Ingress Controller and, consequently, steal all cluster's secrets. This vulnerability affects version 1.8.0 and lower.
### Technologies affected {#technologies-affected}
NGINX
### Vulnerable products and versions {#vulnerable-products-and-versions}
NGINX: Up to version 1.9.0
### Recommendations for vulnerability detection and additional materials {#recommendations-for-vulnerability-detection}
Here is what we recommend in order to avoid exploiting these vulnerabilities:
1. Update NGINX Ingress Controller to 1.9.0; this version has annotation validation, while the custom snippets are disabled by default.
1. Add the `--enable-annotation-validation` argument to the controller startup options.
1. Add the `strict-validate-path-type` option to `Configmap`.
1. Use a policy engine, such as [Kyverno](https://yandex.cloud/en/marketplace/products/yc/kyverno), to validate the paths used in the Ingress rules. You can find [this ready-to-use policy](https://kyverno.io/policies/nginx-ingress/restrict-ingress-paths/restrict-ingress-paths/) on the Kyverno website.
### Safe version of vulnerable product or patch {#safe-version}
The vulnerability has been fixed as of version 1.9.0.
### How it impacts Yandex Cloud services {#impact-on-yandex-cloud-services}
These vulnerabilities are irrelevant when using Yandex Cloud ALB Ingress Controller, as it is based on different technologies and does not have any annotations or settings that may lead to such vulnerabilities.
## 26/10/2023: CVE-2023-3484 GitLab Security Release: 16.1.2, 16.0.7, and 15.11.11 {#CVE-2023-3484}
CVE ID: CVE-2023-3484
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
GitLab closed CVE-2023-3484.
An issue has been discovered in GitLab EE affecting all versions starting from 12.8 before 15.11.11, all versions starting from 16.0 before 16.0.7, all versions starting from 16.1 before 16.1.2. An attacker could change the name or path of a public top-level group in certain situations.
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
GitLab CE/EE, versions prior to 16.1.2, 16.0.7, and 15.11.11
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 3.1 to 6.1
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in GitLab CE/EE versions starting from 16.1.2, 16.0.7, and 15.11.11
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated current and upcoming images and upcoming Managed Service for GitLab instances to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 26/10/2023: CVE-2023-3424, CVE-2023-1936 GitLab Security Release: 16.1.1, 16.0.6, and 15.11.10 {#CVE-2023-3424-CVE-2023-1936}
CVE ID: CVE-2023-3424 - CVE-2023-1936
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
GitLab issued a security release that fixes multiple vulnerabilities. View the complete list here:
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
GitLab CE/EE, versions prior to 16.1.1, 16.0.6, and 15.11.10
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 3.5 to 7.5
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in GitLab CE/EE versions starting from 16.1.1, 16.0.6, and 15.11.10
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated current and upcoming images and upcoming Managed Service for GitLab instances to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 26/10/2023: CVE-2023-2442, CVE-2023-2013 GitLab Security Release: 16.0.2, 15.11.7, and 15.10.8 {#CVE-2023-2442-CVE-2023-2013}
CVE ID: CVE-2023-2442 - CVE-2022-2013
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
GitLab issued a security release that fixes multiple vulnerabilities. View the complete list here:
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
GitLab CE/EE, versions prior to 16.0.2, 15.11.7, and 15.10.8
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 2.6 to 8.7
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in GitLab CE/EE versions starting from 16.0.2, 15.11.7, and 15.10.8
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated current and upcoming images and upcoming Managed Service for GitLab instances to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 16/10/2023: BDU-2023-05857 Vulnerability in the landing module of the 1C-Bitrix Content Management System (CMS) {#BDU-2023-05857}
CVE ID: BDU:2023-05857
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
The vulnerability in the landing module of the 1C-Bitrix Content Management System (CMS) is caused by synchronization errors when using a shared resource. By exploiting this vulnerability, a remote attacker might execute OS commands on a compromised node, gain control over resources, and penetrate the internal network.
### Technologies affected {#technologies-affected}
1C-Bitrix: Site management
### Vulnerable products and versions {#vulnerable-products-and-versions}
Up to 23.850.0
### Vendor {#vendor}
1C-Bitrix LLC
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 10. Attack vector: CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
*
*
*
*
*
### Safe version of vulnerable product or patch {#safe-version}
Landing version 23.850.0 and higher.
### Compensatory measures for Yandex Cloud users {#compensatory-measures}
Update the software product to landing version 23.850.0 or higher.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated current and upcoming images to the latest version. Check your current software version and update it if needed. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 06/10/2023: CVE-2023-35943 CORS filter segfault when origin header is removed {#CVE-2023-35943}
CVE ID: CVE-2023-35943
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
Prior to versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, the CORS filter would segfault and crash Envoy when the `origin` header was removed and deleted between `decodeHeaders` and `encodeHeaders`. The issue is fixed in versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12.
### Technologies affected {#technologies-affected}
Envoy
### Vulnerable products and versions {#vulnerable-products-and-versions}
Envoy, versions prior to 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12.
### Vendor {#vendor}
Envoy
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 7.5. Attack vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
We recommend updating to the latest version. If it is not possible, do not remove the `origin` header in the Envoy configuration.
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability fixed in versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated current and upcoming images to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 06/10/2023: CVE-2023-35941 OAuth2 credentials exploit with permanent validity {#CVE-2023-35941}
CVE ID: CVE-2023-35941
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
Prior to versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, malicious clients could construct OAuth2 credentials with permanent validity. This was caused by some rare scenarios when a HMAC payload could be always valid in the OAuth2 filter's check. As a workaround, avoid wildcards/prefix domain wildcards in the host domain configuration.
### Technologies affected {#technologies-affected}
Envoy
### Vulnerable products and versions {#vulnerable-products-and-versions}
Envoy, versions prior to 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12.
### Vendor {#vendor}
Envoy
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 9.8. Attack vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
We recommend updating to the latest version. If it is not possible, do not use wildcards/prefix domain wildcards in the host domain configuration.
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability fixed in versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated current and upcoming images to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 03/07/2023: CVE-2023-2478 GitLab Critical Security Release: 15.11.2, 15.10.6, and 15.9.7 {#CVE-2023-2478}
CVE ID: CVE-2023-2478
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
Gitlab fixed CVE-2023-2478.
An issue has been discovered in GitLab CE/EE affecting all versions starting from 15.4 before 15.9.7, starting from 15.10 before 15.10.6, and starting from 15.11 before 15.11.2. Under certain conditions, a malicious unauthorized GitLab user may use a GraphQL endpoint to attach a malicious GitLab runner to any project.
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
GitLab CE/EE versions prior to 15.11.2, 15.10.6, and 15.9.7.
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 9.6. Attack vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in versions 15.11.2, 15.10.6, and 15.9.7.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated current and upcoming images and upcoming Managed Service for GitLab instances to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 03/07/2023: CVE-2023-27561 Race-condition to bypass masked paths {#CVE-2023-27561}
CVE ID: CVE-2023-27561
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
Prior to version 1.1.4, `runc` has incorrect access control settings that lead to privilege escalation related to `libcontainer/rootfs_linux.go`. To exploit the vulnerability, an attacker should be able to create two containers with custom mount volume configurations and run custom images.
### Technologies affected {#technologies-affected}
Linux kernel (runc)
### Vulnerable products and versions {#vulnerable-products-and-versions}
`Runc` prior to version 1.1.5.
### Vendor {#vendor}
Linux kernel
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 7.0. Attack vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
We recommend updating to the latest version.
*
*
*
*
*
### Safe version of vulnerable product or patch {#safe-version}
The vulnerability has been fixed as of version 1.1.5.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated current and upcoming images that use `runc` to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 03/07/2023: CVE-2023-27492 Crash when a large request body is processed in Lua filter {#CVE--2023-27492}
CVE ID: CVE-2023-27492
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, the Lua filter was vulnerable to denial of service. Attackers can send large request bodies for routes with the Lua filter enabled and trigger crashes. As of versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, Envoy no longer invokes the Lua coroutine if the filter has been reset.
### Technologies affected {#technologies-affected}
Envoy
### Vulnerable products and versions {#vulnerable-products-and-versions}
Envoy versions prior to 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9.
### Vendor {#vendor}
Envoy
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 6.5. Attack vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
Update to the latest version.
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated the component used in our services to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 03/07/2023: CVE-2023-27491 Envoy forwards invalid HTTP/2 and HTTP/3 downstream headers {#CVE-2023-27491}
CVE ID: CVE-2023-27491
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
HTTP/1 compatible service must reject incorrectly generated request lines. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, invalid HTTP/1 service might allow incorrect requests to be executed, which could help attackers bypass security policies.
### Technologies affected {#technologies-affected}
Envoy
### Vulnerable products and versions {#vulnerable-products-and-versions}
Envoy versions prior to 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9.
### Vendor {#vendor}
Envoy
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 9.1. Attack vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
Update to the latest version.
*
*
*
*
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated the component used in our services to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 03/07/2023: CVE-2022-3513 - CVE-2022-3375. GitLab Security Release: 15.10.1, 15.9.4, and 15.8.5 {#CVE-2022-3513-CVE-2022-3375}
CVE ID: CVE-2022-3513 - CVE-2022-3375
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
GitLab issued a security release that fixes multiple vulnerabilities. View the complete list here:
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
GitLab CE/EE versions prior to 15.10.1, 15.9.4, and 15.8.5.
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
CVSS score: 3.1 to 6.1.
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in versions 15.10.1, 15.9.4, and 15.8.5.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We updated current and upcoming images and upcoming Managed Service for GitLab instances to the latest version. If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 13/04/2023: CVE-2023-26463: StrongSwan IPsec: Incorrectly Accepted Untrusted Public Key With Incorrect Refcount {#CVE-2023-26463}
CVE ID: CVE-2023-26463
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
The TLS implementation in `libtls` incorrectly treats the public key from the peer's certificate as trusted, even if the certificate cannot be verified successfully. However, the public key does not have the correct reference count either, which then causes a dereference of an expired pointer. This commonly leads to a segmentation fault and a denial of service; however, the information exposure or code execution might still be possible.
An attacker is able to trigger this issue by sending a self-signed (or otherwise untrusted) certificate to a server that authenticates clients with a TLS-based EAP method, such as EAP-TLS. Clients may be similarly vulnerable to attackers that send them a request for such an EAP method followed by an untrusted server certificate. Affected versions: StrongSwan 5.9.8 and 5.9.9.
### Technologies affected {#technologies-affected}
StrongSwan IPsec
### Vulnerable products and versions {#vulnerable-products-and-versions}
StrongSwan IPsec prior to 5.9.10
### Vendor {#vendor}
StrongSwan IPsec
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Not rated as of 29/03/2023.
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
*
*
Servers that do not load plugins that implement TLS-based EAP methods (EAP-TLS, EAP-TTLS, EAP-PEAP, or EAP-TNC) are not vulnerable. If these plugins are loaded, they must not be used as a remote authentication method. You should not use the `eap-dynamic` plugin either, since it allows clients to choose their preferred EAP method. Servers that use TLS-based methods via the `eap-radius` plugin and only configure that as a remote authentication method are also not vulnerable.
### Safe version of vulnerable product or patch {#safe-version}
StrongSwan IPsec starting with version 5.9.10.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
The [StrongSwan IPsec image](https://yandex.cloud/en/marketplace/products/yc/ipsec-instance-ubuntu) in Yandex Cloud Marketplace is not vulnerable according to . If you are using a custom image on your VMs and it is vulnerable, we recommend that you update it on your own.
## 13/04/2023: CVE-2023-0286: OpenSSL Security Advisory 7/02/2023 {#CVE-2023-0286}
CVE ID: CVE-2023-0286
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
OpenSSL issued a patch to fix some vulnerabilities, including the critical CVE-2023-0286.
### Technologies affected {#technologies-affected}
OpenSSL
### Vulnerable products and versions {#vulnerable-products-and-versions}
OpenSSL 1.0.2, 1.1.1, and 3.0.0-3.0.7.
### Vendor {#vendor}
OpenSSL
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Base Score: 7.4 HIGH
Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
We recommend updating OpenSSL to the latest version.
### Safe version of vulnerable product or patch {#safe-version}
If you are using OpenSSL 3.0.0-3.0.7, upgrade to OpenSSL 3.0.8.
If you are using OpenSSL 1.1.1, upgrade to OpenSSL 1.1.1t.
If you are using OpenSSL 1.0.2, upgrade to OpenSSL 1.0.2zg.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We collected the latest OpenSSL versions and implemented them in the images being used. If you are using previous OS versions from Yandex Cloud Marketplace with OpenSSL 1.0.2, 1.1.1, or 3.0.0, you need to upgrade OpenSSL on your own.
## 22/02/2023: CVE-2022-3602, CVE-2022-3786: OpenSSL Security release v.3.0.7 {#CVE-2022-3602-CVE-2022-3786}
CVE ID: CVE-2022-3602, CVE-2022-3786.
Links to CVE:
### Original report {#original-report}
### Summary {#brief-description}
The OpenSSL project released a patch to fix critical buffer overflow vulnerabilities triggered by X.509 certificate verification. The CVE-2022-3602 and CVE-2022-3786 vulnerabilities were fixed in OpenSSL version 3.0.7.
### Technologies affected {#technologies-affected}
OpenSSL
### Vulnerable products and versions {#vulnerable-products-and-versions}
OpenSSL prior to version 3.0.7.
### Vendor {#vendor}
OpenSSL
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Base Score: 7.5 HIGH
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
If you are using OpenSSL, we recommend that you upgrade to version 3.0.7 or higher.
### Safe version of vulnerable product or patch {#safe-version}
OpenSSL starting from version 3.0.7.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
We collected the latest OpenSSL versions and implemented them in the images being used. In cloud resources, the vulnerable component is not found among the loaded modules and installed packages.
If you are using previous OS versions from Cloud Marketplace with OpenSSL older than 3.0.7, you need to upgrade OpenSSL on your own.
## 07/02/2023: CVE-2022-3411, CVE-2022-4138, CVE-2022-3759, CVE-2023-0518,: GitLab Security Release: 15.8.1, 15.7.6, 15.6.7 {#CVE-2022-3411-4138-3759-CVE-2023-0518}
CVE ID: CVE-2022-3411, CVE-2022-4138, CVE-2022-3759, and CVE-2023-0518.
Links to CVE:
### Original report {#original-report}
### Brief description {#brief-description}
Multiple vulnerabilities. Complete list: .
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
GitLab CE/EE versions prior to 15.8.1, 15.7.6, and 15.6.7.
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
6.5-4.3
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in versions 15.8.1, 15.7.6, and 15.6.7.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
For the convenience of Managed Service for GitLab users, we already updated current and upcoming instances to the latest version. If you are using images on your VMs, we recommend that you update them on your own.
## 02/02/2022, CVE-2022-41903 and CVE-2022-23521: GitLab Critical Security Release: 15.7.5, 15.6.6, 15.5.9 {#CVE-2022-41903-23521}
CVE ID: CVE-2022-41903 and CVE-2022-23521
Links to CVE:
### Original report {#original-report}
### Brief description {#brief-description}
Multiple vulnerabilities. View the complete list here: .
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
GitLab CE/EE versions prior to 15.7.5, 15.6.6, and 15.5.9.
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Severity level: 9.9.
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in versions 15.7.5, 15.6.6, and 15.5.9.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
For the convenience of Managed Service for GitLab users, we already updated current and upcoming instances to the latest version. If you are using images on your VMs, we recommend that you update them on your own.
## 26/12/2022: CVE-2022-47940: KSMBD FS/KSMBD/SMB2PDU.C SMB2_WRITE {#CVE-2022-47940}
CVE ID: CVE-2022-47940
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel. Authentication is required to exploit this vulnerability. The specific flaw exists within the handling of SMB2_WRITE commands. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the kernel. To be vulnerable, needs ksmbd-tools installed to enable the ksmbd service, which is not installed by default.
### Technologies affected {#technologies-affected}
Linux Kernel.
### Vulnerable products and versions {#vulnerable-products-and-versions}
Linux Kernel up to 5.18.17
ksmbd-tools
### Vendor {#vendor}
ksmbd-tools
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Severity level: 4.1
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
The vulnerability is fixed as of Linux Kernel version 5.18.18.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
The vulnerable component is not present among loaded modules and installed components in cloud services.
If you are using vulnerable OS images from Marketplace in Yandex Compute Cloud, you have to update them to secure versions yourself.
## 06/12/2022: CVE-2022-28228: Out-of-bounds reads in YDB servers {#CVE-2022-28228}
_Updated on 08/12/2022_
Vulnerability reported by: Max Arnold
CVE ID: CVE-2022-28228
CVE link:
### Original report {#original-report-CVE-2022-28228}
### Summary {#brief-description-CVE-2022-28228}
Hackers can create special requests that trigger errors. An error message can include fragments of data from another cluster. Hackers can also run a denial of service attack against clusters.
### Technologies affected {#technologies-affected}
Yandex Managed Service for YDB in serverless mode.
### Vulnerable products and versions {#vulnerable-products-and-versions-CVE-2022-28228}
All the versions below 22.4.44 have this vulnerability.
Version 22.4.44 is safe.
### Vendor {#vendor-CVE-2022-28228}
Yandex
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection-CVE-2022-28228}
### Safe version of vulnerable product or patch {#safe-version-CVE-2022-28228}
Any version from 22.4.44 or higher.
### Compensatory measures for Yandex Cloud users {#compensatory-measures-CVE-2022-28228}
Everything has been done at the service level, no additional action is needed.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services-CVE-2022-28228}
Only Yandex Managed Service for YDB in the serverless mode was subject to the vulnerability. The vulnerability is closed at present: all the YDB instances were updated to the safe version.
## 03/11/2022: CVE-2022-42889: Text4Shell {#CVE-2022-42889}
CVE ID: CVE-2022-42889
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
The vulnerability was found in a number of Apache Commons Text library versions. Applications using default string interpolation parameters may be vulnerable to remote code execution or unintentional contact with untrusted remote servers.
### Technologies affected {#technologies-affected}
Apache Commons Text
### Vulnerable products and versions {#vulnerable-products-and-versions}
The vulnerability affects versions 1.5 through 1.9.
Version 1.10.0 is safe.
### Vendor {#vendor}
Apache Software Foundation
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Severity level: 9.8_Critical.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
*
*
*
### Safe version of vulnerable product or patch {#safe-version}
The vulnerability is fixed as of version 1.10.0.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
The library has been upgraded to the safe version in Yandex Cloud services where it is used.
## 01/09/2022: CVE-2022-2992: GitLab Critical Security Release: 15.3.2, 15.2.4, and 15.1.6 {#CVE-2022-2992}
CVE ID: CVE-2022-2992
Link to CVE:
### Original report {#original-report}
### Brief description {#brief-description}
Multiple vulnerabilities. Complete list: .
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
All GitLab CE/EE versions before 15.3.2, 15.2.4, and 15.1.6 are affected.
The vulnerability was fixed in versions 15.3.2, 15.2.4, and 15.1.6.
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Severity level: 9.9.
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of vulnerable product or patch {#safe-version}
Vulnerability resolved in versions 15.3.2, 15.2.4, and 15.1.6.
### Compensatory measures for Yandex Cloud users {#compensatory-measures}
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
The vulnerability affects the users of Managed Service for GitLab and GitLab images from Cloud Marketplace.
All GitLab images in Managed Service for GitLab and Cloud Marketplace are being updated to safe versions.
## 31/08/2022: CVE-2020-8561, Redirecting Kubernetes API server requests {#CVE-2020-8561}
CVE ID: CVE-2020-8561
CVE link:
### Original report {#original-report-CVE-2020-8561}
### Summary {#brief-description-CVE-2020-8561}
In Kubernetes, a user who monitors responses to `MutatingWebhookConfiguration` or `ValidatingWebhookConfiguration` requests can redirect `kube-apiserver` requests to private networks hosting an API server. If the logging level is `10`, logs will capture responses from such private networks.
### Technologies affected {#technologies-affected-CVE-2020-8561-CVE-2020-8561}
Kubernetes
### Vulnerable products and versions {#vulnerable-products-and-versions-CVE-2020-8561}
All Kubernetes versions.
### Vendor {#vendor-CVE-2020-8561}
Kubernetes
### Attack vector and severity level as per CVSS v.3.0 {#attack-vector-and-severity-level-CVE-2020-8561}
Severity level: 4.1.
AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection-CVE-2020-8561}
### Safe version of vulnerable product or patch {#safe-version-CVE-2020-8561}
No patches or safe versions.
### Compensatory measures for Yandex Cloud users {#compensatory-measures-CVE-2020-8561}
Block access to resources with sensitive information for `kube-apiserver`.
You can also set a value below `10` for the `-v` flag and `false` for the `--profiling` flag (the default value is `true`). Webhook requests will be redirected to private networks, but logs will not capture the request body if the logging level is below `10`. Users will not be able to modify the `kube-apiserver` logging level.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services-CVE-2020-8561}
No impact. The API serer in Yandex Managed Service for Kubernetes is isolated from the service interface. The server runs under an individual user account that is isolated by a local firewall.
## 25/08/2022: CVE-2022-2884: Remote Command Execution via GitHub import in GitLab {#CVE-2022-2884}
_Updated on 01/09/2022_
CVE ID: CVE-2022-2884
Link to CVE:
### Original report {#original-report}
### Summary {#brief-description}
A vulnerability in GitLab CE/EE allows an authenticated user to achieve remote code execution via the Import from GitHub API endpoint.
### Technologies affected {#technologies-affected}
GitLab
### Vulnerable products and versions {#vulnerable-products-and-versions}
The following GitLab CE/EE versions are vulnerable:
* Between 11.3.4 and 15.1.5.
* Between 15.2 and 15.2.3.
* Between 15.3 and 15.3.1.
The vulnerability was fixed in versions 15.1.5, 15.2.3, and 15.3.1.
### Vendor {#vendor}
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0 {#attack-vector-and-severity-level}
Severity level: 9.9.
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
### Recommendations for vulnerability detection and supporting materials {#recommendations-for-vulnerability-detection}
### Safe version of the vulnerable product or patch {#safe-version}
The vulnerability was fixed in GitLab CE/EE 15.1.5, 15.2.3, and 15.3.1.
### Compensatory measures for Yandex Cloud users {#compensatory-measures}
Disable import from GitHub to GitLab:
1. Log in to your GitLab installation using an administrator account.
1. Click **Menu** → **Admin**.
1. Click **Settings** → **General**.
1. Expand **Visibility and access controls**.
1. Under **Import sources**, disable the **GitHub** option.
1. Click **Save changes**.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services}
The vulnerability doesn't affect Yandex Cloud users. GitLab in Managed Service for GitLab and Cloud Marketplace has been updated to a safe version.
## 04/07/2022: CVE-2022-27228: Vulnerability of "vote" module in CMS 1C-Bitrix {#CVE-2022-27228}
CVE ID: CVE-2022-27228
Link to CVE:
### Original report
### Brief description
Vulnerability of the "vote" module in the 1C-Bitrix content management system (CMS): website management linked to ability to send special network packets. The exploit may enable a hacker to write arbitrary files remotely to a vulnerable system.
### Technologies affected
Bitrix CMS
### Vulnerable products and versions
All versions before 21.0.100.
### Vendor
1C-Bitrix
### Attack vector and severity level per CVSS v.3.0
Severity level: 9,8
### Recommendations for vulnerability detection and supporting materials
Requests for `/bitrix/tools/composite_data.php`, `/bitrix/tools/html_editor_action.php`, `/bitrix/admin/index.php`, `/bitrix/tools/vote/uf.php`.
### Safe version of vulnerable product or patch
Vulnerability resolved in "vote" module version 21.0.100.
### Compensatory measures for Yandex Cloud users
Additional validation of inputs to the "vote" module including WAF validation.
### Impact on Yandex Cloud services
No impact on Yandex Cloud services.
## 22/06/2022: CVE-2022-1680: GitLab account takover, critical vulnerability {#CVE-2022-1680}
CVE ID: CVE-2022-1680
Link to CVE:
### Original report
### Brief description
When SAML SSO and SCIM are used for a premium GitLab group, any group owner can invite arbitrary users into the group, change those users' email address via SCIM, and take over those users' accounts (unless two-factor authentication is being used).
### Technologies affected
Gitlab
### Vulnerable products and versions
The following GitLab Enterprise Edition (EE) versions are vulnerable:
* Between 11.10 and 14.9.5.
* Between 14.10 and 14.10.4.
* Between 15.0 and 15.0.1.
In versions 15.0.1, 14.10.4, and 14.9.5, the vulnerability has been eliminated.
### Vendor
GitLab Inc.
### Attack vector and severity level per CVSS v.3.0
Severity level: 9.9
### Recommendations for vulnerability detection and supporting materials
If you are using a custom GitLab installation, check whether `group_saml` has been enabled .
### Safe version of vulnerable product or patch
Vulnerability resolved in versions 15.0.1, 14.10.4, and 14.9.5.
### Compensatory measures for Yandex Cloud users
* Yandex Compute Cloud
GitLab images for Yandex Compute Cloud in Yandex Cloud Marketplace have been updated to a safe version.
Yandex Compute Cloud users with deprecated GitLab images from Yandex Cloud Marketplace or deprecated custom installations may be subject to the vulnerability.
Update to the latest version.
* Yandex Managed Service for GitLab
For Yandex Managed Service for GitLab users (at the preview stage), the GitLab version has been updated to a safe version.
No additional action on the part of the users is required.
## 15/06/2022: CVE-2021-25748: Ingress-nginx. Path sanitization bypass {#CVE-2021-25748}
CVE ID: CVE-2021-25748
Link to CVE:
### Original report
### Brief description
The user can bypass sanitization of the `spec.rules[].http.paths[].path` field of an ingress object (in the networking.k8s.io or extensions API group) by using a newline character in the field value to obtain the credentials of the ingress-nginx controller. In the default configuration, that credential has access to all secrets in the cluster.
### Involved technologies
* Kubernetes
* Nginx
### Affected products and versions
ingress-nginx < v1.2.1
### Vendor
NGINX ingress controller
### Attack vector and severity level according to CVSS v.3.0
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L
### Recommendations for vulnerability detection and supporting materials
### Safe version of the vulnerable product or patch
ingress-nginx v1.2.1
### Compensatory measures for Yandex Cloud users
If you are using ingress-nginx controller in Yandex Managed Service for Kubernetes or self-hosted Kubernetes and are unable to roll out the fix, use a policy that restricts the `spec.rules[].http.paths[].path` field of the networking.k8s.io/Ingress resource to safe characters (see the newly added [rules](https://github.com/kubernetes/ingress-nginx/blame/main/internal/ingress/inspector/rules.go) and the suggested values for [annotation-value-word-blocklist](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#annotation-value-word-blocklist)).
### Impact on Yandex Cloud services
There is no impact on Yandex Cloud services, since the infrastructure does not use ingress-nginx. The [alb-ingress controller](../../application-load-balancer/tools/k8s-ingress-controller/index.md) is used instead.
## 29.04.2022: CVE-2022-24735 and CVE-2022-24736: Redis {#cve-2022-24735-24736}
### Description {#description-CVE-2022-24735-24736}
#### CVE-2022-24735 {#CVE-2022-24735-CVE-2022-24735-24736}
Vulnerability [CVE-2022-24735](https://nvd.nist.gov/vuln/detail/CVE-2022-24735) is used to exploit weaknesses in the Lua script execution environment. An attacker with access to Redis prior to version 7.0.0 or 6.2.7 can inject Lua code that will execute with the higher privileges of another Redis user.
For a detailed description of the vulnerability, see this [article](https://github.com/redis/redis/security/advisories/GHSA-647m-2wmq-qmvq).
Vulnerability description: [CVE-2022-24735](https://nvd.nist.gov/vuln/detail/CVE-2022-24735).
CVSS rating: [3.9 LOW](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2022-24735&vector=AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N&version=3.1&source=GitHub,%20Inc.).
#### CVE-2022-24736 {#CVE-2022-24736-CVE-2022-24735-24736}
Vulnerability [CVE-2022-24736](https://nvd.nist.gov/vuln/detail/CVE-2022-24736) is used by an attacker to load a specially crafted Lua script, which will result in a crash of Redis prior to version 7.0.0 and 6.2.7.
For a detailed description of the vulnerability, see this [article](https://github.com/redis/redis/security/advisories/GHSA-3qpw-7686-5984).
Vulnerability description: [CVE-2022-24736](https://nvd.nist.gov/vuln/detail/CVE-2022-24736).
CVSS rating: [3.3 LOW](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2022-24736&vector=AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L&version=3.1&source=GitHub,%20Inc.).
### Impact {#impact-CVE-2022-24735-24736}
#### General impact {#overall-impact-CVE-2022-24735-24736}
All Redis databases prior to version 7.0.0 and 6.2.7 are affected.
#### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services-CVE-2022-24735-24736}
Yandex Managed Service for Valkey™ uses the following Redis versions: 5.0, 6.0, 6.2.
The following measures are being taken to mitigate the vulnerability in Yandex Cloud services:
* All instances of version 6.2 will be upgraded to the updated version 6.2.7. The upgrade will occur following the standard cluster settings.
* For versions 6.0 or 5.0, the vendor has not released updates. Users need to upgrade to version 6.2 themselves in order to get the standard update to version 6.2.7.
### Compensatory measures {#compensatory-measures-CVE-2022-24735-24736}
If you are using Redis version 6.0 or 5.0 as part of Yandex Managed Service for Valkey™, upgrade to version 6.2 as soon as possible.
If you are using your own Redis installation, upgrade to version 6.2.7 or 7.0.0. If an upgrade isn't currently possible, the vendor has released a [workaround](https://github.com/redis/redis/security/advisories/GHSA-3qpw-7686-5984).
## 06/04/2022: CVE-2022-1162: GitLab Critical Security Release {#CVE-2022-1162}
### Description {#description-CVE-2022-1162}
GitLab has published an overview of a number of vulnerabilities in their [article](https://about.gitlab.com/releases/2022/03/31/critical-security-release-gitlab-14-9-2-released/).
The vulnerability was discovered internally and assigned the ID CVE-2022-1162. The vulnerability affects both GitLab Community Edition (CE) and Enterprise Edition (EE):
* All versions through 14.7.7.
* All versions from 14.8 through 14.8.5.
* All versions from 14.9 through 14.9.2.
The vulnerability results from hardcoded passwords being set inadvertently during OmniAuth-based registration in GitLab CC/EE.
This is an unscheduled release which is also the March monthly release.
GitLab has prepared a [script](https://about.gitlab.com/releases/2022/03/31/critical-security-release-gitlab-14-9-2-released/#script-to-identify-users-potentially-impacted-by-cve-2022-1162) to use to identify user accounts that are potentially vulnerable to CVE-2022-1162.
### Impact on Yandex Cloud services {#impact-on-yandex-cloud-services-CVE-2022-1162}
#### Yandex Compute Cloud {#compute-CVE-2022-1162}
A GitLab image for Yandex Compute Cloud in Yandex Cloud Marketplace was updated to the latest version.
Potentially, the vulnerability affects all Yandex Compute Cloud users utilizing deprecated GitLab images from Yandex Cloud Marketplace or deprecated custom images. These users must reinstall their systems using an updated Marketplace image or update their GitLab to the most recent version.
Yandex Cloud sent out notifications to all users with a deprecated GitLab image.
#### Yandex Managed Service for GitLab {#managed-gitlab-CVE-2022-1162}
For anyone using Yandex Managed Service for GitLab in test mode in a Yandex Cloud, we have already updated the existing and future instances to the latest version.
Yandex Cloud sent out notifications to all Yandex Managed Service for GitLab users.
### Compensatory measures {#compensatory-measures-CVE-2022-1162}
Potentially, the vulnerability affects all users using deprecated custom GitLab images. These users need to upgrade their GitLab version to the latest one.
## 18/03/2022: CVE-2022-0811: cr8escape {#CVE-2022-0811}
### Description
CrowdStrike security researchers discovered a new vulnerability in the CRI-O container engine that can be used in Kubernetes. It can be exploited by an attacker with rights to deploy a pod to escape a container, gain root privileges, and move anywhere in the cluster.
The issue is that, starting from CRI-O 1.19, the sysctl system parameters can be overridden, for example, by abusing kernel.core_pattern to escape a container.
Original report: [article](https://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/).
Vulnerability description: [CVE-2022-0811](https://nvd.nist.gov/vuln/detail/CVE-2022-0811).
### Impact on Yandex Cloud services
There is no impact, since CRI-O is not used in Managed Service for Kubernetes.
### Compensatory measures
If you're using Kubernetes as a custom bare metal installation rather than within Managed Service for Kubernetes:
* Update the CRI-O to version 1.23.2.
* If there is no patch with updates for your OS, roll back the CRI-O version to 1.18 or lower.
* If you can't change the CRI-O version:
1. Apply the policy that disallows"+" or "=" in sysctl values.
2. PodSecurityPolicy [forbiddenSysctls](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#sysctl) to forbid any sysctl.
## 09/03/2022: CVE-2022-0847: Dirty Pipe {#CVE-2022-0847}
Updated on 17/03/2022
### Description
The vulnerability has been discovered in Linux. The vulnerability allows data to be overwritten in read-only official files.
The vulnerability is relevant for kernel versions from 5.8.
The vulnerability was fixed in versions 5.16.11, 5.15.25 and 5.10.102.
Original report: [article](https://arstechnica.com/information-technology/2022/03/linux-has-been-bitten-by-its-most-high-severity-vulnerability-in-years/).
Vulnerability description: [CVE-2022-0847](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0847).
### Impact on Yandex Cloud services
The vulnerability does not affect the Yandex Cloud services, as the infrastructure uses kernel versions that are different from those affected by the vulnerability.
Several VM images from Cloud Marketplace were affected:
* ubuntu-20-04-lts-gpu
* ubuntu-20-04-lts-gpu-a100
### Compensatory measures
The affected VM images have been removed from Cloud Marketplace and replaced with updated images.
If you are using a VM image that is affected by the vulnerability, update according to the official documentation.
Example for Ubuntu: https://ubuntu.com/security/notices/USN-5317-1.
## 28/02/2022: CVE-2022-0735 (token disclosure), CVE-2022-0549, CVE-2022-0751, CVE-2022-0741, CVE-2021-4191, CVE-2022-0738, CVE-2022-0489: Multiple GitLab vulnerabilities {#multiple-GitLab-vulnerabilities}
### Description
GitLab Inc. published an overview of a number of vulnerabilities in their [article](https://about.gitlab.com/releases/2022/02/25/critical-security-release-gitlab-14-8-2-released/).
#### CVE-2022-0735
The most severe vulnerability is [CVE-2022-0735](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0735) "Runner registration token disclosure through Quick Actions".
It affects the following versions:
* All versions from 12.10 to 14.6.5 inclusive.
* All versions from 14.7 to 14.7.4 inclusive.
* All versions from 14.8 to 14.8.2 inclusive.
Other vulnerabilities are less critical.
#### CVE-2022-0549
CVE-2022-0549 "Unprivileged users can add other users to groups through an API endpoint" is a medium severity issue.
It affects the following versions:
* All versions from 14.4 to 14.4.4 inclusive.
* All versions from 14.5 to 14.5.2 inclusive.
#### CVE-2022-0751
CVE-2022-0751 "Inaccurate display of Snippet contents can be potentially misleading to users" is a medium severity issue.
#### CVE-2022-0741
CVE-2022-0741 "Environment variables can be leaked via the sendmail delivery method" is a medium severity issue.
#### CVE-2021-4191
CVE-2021-4191 "Unauthenticated user enumeration on GraphQL API" is a medium severity issue and applies to all versions from 14.4 to 14.8 inclusive.
#### CVE-2022-0738
CVE-2022-0738 "Adding a pull mirror with SSH credentials can leak password" is a medium severity issue.
It affects the following versions:
* All versions from 14.6 to 14.6.5 inclusive.
* All versions from 14.7 to 14.7.4 inclusive.
* All versions from 14.8 to 14.8.2 inclusive.
#### CVE-2022-0489
CVE-2022-0489 "Denial of Service via user comments" is a minor severity issue and can affect all new versions starting from 8.15.
#### Links
For more information about vulnerabilities, see the [original GitLab report](https://about.gitlab.com/releases/2022/02/25/critical-security-release-gitlab-14-8-2-released/).
Description of vulnerabilities:
* [CVE-2022-0735](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0735)
* [CVE-2022-0549](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0549)
* [CVE-2022-0751](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0751)
* [CVE-2022-0741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0741)
* [CVE-2021-4191](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4191)
* [CVE-2022-0738](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0738)
* [CVE-2022-0489](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0489)
### Impact on Yandex Cloud services
#### Yandex Compute Cloud
A GitLab image for Yandex Compute Cloud in Yandex Cloud Marketplace was updated to the latest version.
All Yandex Compute Cloud users who have used GitLab images from Cloud Marketplace or their own images are potentially vulnerable. These users need to reinstall the system from the current Cloud Marketplace image or upgrade their GitLab version to the latest one by following the [official instructions](https://about.gitlab.com/releases/2022/02/25/critical-security-release-gitlab-14-8-2-released/).
If you can't upgrade the GitLab version, take compensatory measures.
Notifications with update recommendations were sent to all users who are using a deprecated GitLab image from Cloud Marketplace.
#### Yandex Managed Service for GitLab
For users of Managed Service for GitLab, which is now being tested in Yandex Cloud, we already updated current and upcoming instances to the latest version.
All Yandex Managed Service for GitLab users have been sent notification.
### Compensatory measures {#multiple-GitLab-vulnerabilities-compensatory-measures}
If you can't update now, you can temporarily fix the vulnerability using the [hotpatch](https://about.gitlab.com/releases/2022/02/25/critical-security-release-gitlab-14-8-2-released/#hotpatch-for-runner-registration-token-disclosure-through-quick-actions).
## 28/01/2022: CVE-2022-0185: Heap overflow bug in legacy_parse_param {#CVE-2022-0185}
### Description
Vulnerability [CVE-2022-0185](https://ubuntu.com/security/CVE-2022-0185) is found in Linux kernel versions from 5.1-rc1, in the file system context functionality. An attacker may use this to cause a denial of service (system crash), execute arbitrary code, and go out of container bounds.
For a detailed description of the vulnerability, see this [article](https://sysdig.com/blog/cve-2022-0185-container-escape/).
Vulnerability description: [CVE-2022-0185](https://ubuntu.com/security/CVE-2022-0185).
CVSS score: 7.8.
### Impact
#### General impact
This vulnerability affects Linux Kernel systems around the world that run kernel versions 5.1-rc1 to 5.16.
#### Impact on Yandex Cloud services
Yandex Cloud updated its services:
* Yandex Cloud Marketplace.
* Yandex Cloud internal infrastructure.
We are preparing updates for Yandex Managed Service for Kubernetes.
### Compensatory measures
If you are using a cloud node group in Yandex Managed Service for Kubernetes, wait for the official update for the service and apply it. Alternatively, [update the OS](https://ubuntu.com/security/notices/USN-5240-1) independently.
You can also take the compensatory measures:
* Use a [daemonset fix](https://github.com/yandex-cloud/yc-solution-library-for-security/tree/master/kubernetes-security/cve-quickfix/CVE-2022-0185) for this vulnerability from yc-solution-library-for-security. It sets the settings according to Ubuntu recommendations.
* Follow the official update or vulnerability compensation guidelines for your Linux distribution. For example, set `sysctl -w kernel.unprivileged_userns_clone=0` for Ubuntu.
* Use seccomp in Kubernetes as described in this [article](https://kubernetes.io/docs/tutorials/security/seccomp/).
* Do not assign redundant capabilities and use [the k8s security section](../domains/kubernetes.md#secure-config-1) from our checklist for monitoring them.
## 28/01/2022: CVE-2021-4034: Polkit's pkexec {#cve-2021-4034}
### Description
Vulnerability [CVE-2021-4034](https://ubuntu.com/security/notices/USN-5252-1) is found in all versions of Unix-like operating systems. The PolicyKit pkexec tool incorrectly handles command-line arguments. An attacker may use this pkexec behavior to escalate privileges to an administrator.
For a detailed description of the vulnerability, see this [article](https://www.openwall.com/lists/oss-security/2022/01/25/11).
Vulnerability description: [CVE-2021-4034](https://ubuntu.com/security/notices/USN-5252-1).
CVSS score: 7.8.
### Impact
#### General impact
The vulnerability affects all the Unix-like operating systems running any policykit-1 (0.105) version lower than specified in the article. See here for [Ubuntu](https://ubuntu.com/security/notices/USN-5252-1).
#### Impact on Yandex Cloud services
Yandex Cloud updated its services:
* Yandex Cloud Marketplace.
* Yandex Cloud internal infrastructure.
We are preparing updates for Yandex Managed Service for Kubernetes.
### Compensatory measures
If you are using a cloud-based node group in Yandex Managed Service for Kubernetes, wait for the official update for the service and apply it. Alternatively, [update the OS](https://ubuntu.com/security/notices/USN-5252-1) independently.
You can also take the compensatory measures:
* Use a [daemonset fix](https://github.com/yandex-cloud/yc-solution-library-for-security/tree/master/kubernetes-security/cve-quickfix/CVE-2021-4034) for this vulnerability from yc-solution-library-for-security. It sets the settings according to Ubuntu recommendations.
* Follow the official update or vulnerability compensation guidelines for images from Yandex Cloud Marketplace or your own images in Yandex Compute Cloud. For example, set access rights for Ubuntu: `chmod 0755 /usr/bin/pkexec`.
## 29/12/2021: CVE-2021-45105, CVE-2021-44832: Denial of service and remote code execution (Log4j) {#CVE-2021-45105-CVE-2021-44832}
### Description
Vulnerability CVE-2021-45105 is found in Apache Log4j versions 2.0-alpha through 2.16.0, excluding 2.12.3. The versions do not protect from uncontrolled recursion from self-referential lookups. This may result in a StackOverflowError and a DoS attack.
Vulnerability CVE-2021-44832 is found in Apache Log4j versions 2.0-beta7 through 2.17.0, excluding security fix releases 2.3.2 and 2.12.4. The versions are vulnerable to a remote code execution (RCE) attack where an attacker has permission to modify the logging configuration file.
Original report from [logging.apache.org](https://logging.apache.org/log4j/2.x/security.html).
Vulnerability description: [CVE-2021-45105](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105) and [CVE-2021-44832](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832).
CVSS rating:
* CVE-2021-45105 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
* CVE-2021-44832 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
### Impact
#### General impact
The Log4j library is included in almost all Apache Software Foundation enterprise solutions, such as: Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Kafka, Apache Dubbo, etc.
For a complete list of software affected by the vulnerability, see:
* https://github.com/NCSC-NL/log4shell/tree/main/software
* https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
#### Impact on Yandex Cloud services
Vulnerable versions of the library are not used in Yandex Cloud services.
### Compensatory measures
If your infrastructure uses this library or the products listed in the "General Impact" section, follow the steps below.
#### Log4j 1.x
Log4j 1.x is not affected by the vulnerability.
#### Log4j 2.x
* Java 6: Upgrade to Log4j 2.3.2.
* Java 7: Upgrade to Log4j 2.12.4.
* Java 8 (and later): Upgrade to Log4j 2.17.1.
* If you cannot upgrade the library now, make sure that the JDBC Appender is not configured to use any protocol other than Java.
Note that only the log4j-core JAR file is affected by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not affected by this vulnerability.
Also note that Apache Log4j is the only Logging Services subproject impacted by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this vulnerability.
Source: https://logging.apache.org/log4j/2.x/security.html
You can also use the following tools to scan your infrastructure for the log4j vulnerability:
* https://github.com/google/log4jscanner
* https://github.com/bi-zone/Log4j_Detector
## 17/12/2021: CVE-2021-45046: Remote code execution (Log4j) {#CVE-2021-45046}
### Description
Vulnerability [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046) is found in Apache Log4j versions 2.0-beta9 through 2.15.0, excluding 2.12.2.
It was found that the fix to address the [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) vulnerability in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Attackers can craft malicious input data using a JNDI Lookup pattern. This may result in an information leak and remote and local code execution.
A detailed description of the exploit and this behavior is provided in a [Lunasec article](https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/).
Original report from [logging.apache.org](https://logging.apache.org/log4j/2.x/security.html).
Vulnerability description: [CVE-2021-45046](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046).
CVSSv3.1 rating: 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
### Impact
#### General impact
The Log4j library is included in almost all Apache Software Foundation enterprise solutions, such as: Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Kafka, Apache Dubbo, etc.
For a complete list of software affected by the vulnerability, see:
* https://github.com/NCSC-NL/log4shell/tree/main/software
* https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
#### Impact on Yandex Cloud services
Services that used the Yandex Managed Service for Elasticsearch library, Yandex Data Processing, and a number of basic platform services were successfully updated.
Yandex Cloud has collected information on users that have utilized these services. Appropriate alerts have gone out.
### Compensatory measures
If your infrastructure uses this library or the products listed in the "General Impact" section, follow the steps below.
#### Log4j 1.x
Log4j 1.x is not affected by the vulnerability.
#### Log4j 2.x
* Java 8 (and later): Upgrade to Log4j 2.16.0.
* Java 7: Upgrade to Log4j 2.12.2.
* If you cannot upgrade the library now, remove the `JndiLookup` class from the classpath: `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class`.
Users are advised not to enable JNDI in Log4j 2.16.0. If the JMS Appender is required, use Log4j 2.12.2.
Note that only the `log4j-core JAR` file is affected by this vulnerability. Applications using only the `log4j-api JAR` file without `log4j-core JAR` are not affected.
Source: https://logging.apache.org/log4j/2.x/security.html
## 10/12/2021: CVE-2021-44228: Remote code execution (Log4Shell, Apache Log4j) {#CVE-2021-44228}
Updated on 22.12.2021
### Description
Vulnerability [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) is found in the Apache Log4j library, version 2.14.1 and lower.
A zero-day exploit was discovered that results in remote code execution (RCE) by having a certain line entered into a log.
An attacker with control over log messages or log message parameters can run any code downloaded from LDAP servers provided `message lookup substitution` is on. Starting with log4j version 2.15.0, this behavior is disabled by default.
A detailed description of the exploit and this behavior is provided in a [Lunasec article](https://www.lunasec.io/docs/blog/log4j-zero-day/).
Original report from logging.apache.org: [Fixed in Log4j 2.15.0](https://logging.apache.org/log4j/2.x/security.html).
Vulnerability description: [CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228).
CVSSv3.1 rating: 10.0 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C)
Learn more at: https://www.securitylab.ru/vulnerability/527362.php
### Impact
#### General impact
1. The Log4j library is included in almost all Apache Software Foundation enterprise solutions, such as: Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Kafka, Apache Dubbo, etc.
1. The vulnerability affects such open-source products such as ElasticSearch, Elastic Logstash, the NSA’s Ghidra, etc.
1. Hystax products are vulnerable because they use a vulnerable version of Elasticsearch Logstash.
Hystax is working on new product releases to address the vulnerability.
#### Impact on Yandex Cloud services
Services that used the Yandex Managed Service for Elasticsearch library, Yandex Data Processing, and a number of basic platform services were successfully updated.
Yandex Cloud has collected information on users that have utilized these services. Appropriate alerts have gone out.
### Compensatory measures
If your infrastructure uses this library or the products listed in the "General Impact" section, follow the steps below.
#### Log4j 1.x
Since Log4j 1.x does not support [Lookups](https://logging.apache.org/log4j/2.x/manual/lookups.html), the overall risk of exploiting the vulnerability for applications using Log4j 1.x is low.
Applications using Log4j 1.x are only vulnerable to this attack when they use [JNDI](https://logging.apache.org/log4j/2.x/manual/lookups.html#JndiLookup). In this case, make sure your configuration is not using `JMSAppender`.
#### Log4j 2.x
* Java 8 (and later): Upgrade to Log4j 2.16.0.
* Java 7: Upgrade to release Log4j 2.12.2 as soon as it is available.
* If you cannot upgrade the library now, remove the `JndiLookup` class from the classpath: `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class`.
Note that only the `log4j-core JAR` file is affected by this vulnerability. Applications using only the `log4j-api JAR` file without `log4j-core JAR` are not affected.
Source: https://logging.apache.org/log4j/2.x/security.html
#### Hystax
Hystax Acura Controller: allow ingress traffic for UDP port 12201 only for a list of source IP ranges with replication agents deployed.
If you placed Hystax Acura Controller behind a network load balancer in your infrastructure, apply the above firewall rule to the respective load balancer.
## 12/11/2021: CVE-2021-22205: Remote code execution via a vulnerability in GitLab {#CVE-2021-22205}
### Description
In GitLab versions starting 11.9, a [security issue](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22205) was discovered, which resulted in a remote command execution. An attack may be carried out by sending two requests that require no authentication.
The vulnerability is caused by not properly validating uploaded image files by an external file parser using the ExifTool library ([CVE-2021-22204](https://security-tracker.debian.org/tracker/CVE-2021-22204)).
The issue is fixed in GitLab versions 13.10.3, 13.9.6, and 13.8.8.
### Impact on Yandex Cloud services
A GitLab image in Yandex Cloud Marketplace was updated to the latest version.
Notifications with update recommendations were sent to all users using a deprecated GitLab image.
Yandex Managed Service for GitLab users were not affected by the vulnerability, since the service uses the current GitLab version.
### Compensatory measures
If you are using a deprecated GitLab image from Yandex Cloud Marketplace or a custom image, [update](https://about.gitlab.com/update) it to the latest version. If for some reason you cannot update the GitLab version, use a [hotpatch](https://forum.gitlab.com/t/cve-2021-22205-how-to-determine-if-a-self-managed-instance-has-been-impacted/60918#hotpatch-2).
### Additional information
* [Action needed by self-managed customers in response to CVE-2021-22205](https://about.gitlab.com/blog/2021/11/04/action-needed-in-response-to-cve2021-22205/)
* [GitLab CE CVE-2021-22205 in the wild](https://security.humanativaspa.it/gitlab-ce-cve-2021-22205-in-the-wild/)
## 12/10/2021: CVE-2021-25741: Risk of accessing a host's file system {#CVE-2021-25741}
### Description
A [security issue](https://github.com/kubernetes/kubernetes/issues/104980) was discovered in Kubernetes, which allows unauthorized access to a node's filesystem when a user logs in to a cluster.
### Impact on Yandex Cloud services
Yandex Managed Service for Kubernetes does not provide anonymous cluster access and is not affected by the vulnerability from an external attacker.
### Compensatory measures
To remove the attack vector from an internal attacker, update all existing service clusters and node groups to version 1.19 or higher. If your clusters and node groups are already updated to version 1.19 or higher, update the revisions. An update that fixes the bug is available in all release channels.
We also recommend that you:
* Automatically update your clusters and node groups to the latest versions or revisions.
* Schedule manual updates at least once a month if you cannot apply automatic updates.
* Disable running pods as root for untrusted uploads.
You can do this by using the following tools:
* [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/pod-security-policy/users)
* [Kyverno](https://kyverno.io/policies/pod-security/restricted/require-run-as-nonroot/require-run-as-nonroot/)
### Additional information
A checklist for a secure Kubernetes configuration is available [here](../domains/kubernetes.md).
## 03/03/2021: CVE-2021-21309: Remote code execution via a vulnerability in Valkey™
### Description
In 32-bit Valkey™ versions 4.0 and higher, an integer overflow vulnerability was discovered, which, under certain conditions, may lead to a remote code execution.
### Impact on Yandex Cloud services
Yandex Managed Service for Valkey™ uses 64-bit Valkey™ instances and is not affected by the vulnerability.
## 26/01/2021: CVE-2021-3156: Privilege escalation through vulnerabilities in sudo.
### Description
A number of [CVE-2021-3156](https://nvd.nist.gov/vuln/detail/CVE-2021-3156) vulnerabilities were discovered in `sudo`. They allow attackers to escalate privileges to `root`.
### Impact on Yandex Cloud services
The following Linux OS images were updated:
* All images from the Yandex Cloud publisher available in Cloud Marketplace.
* A Container Optimized Image.
* An image that is used to create Managed Service for Kubernetes nodes.
* Images that are used to create managed database clusters.
* An image that is used to create Yandex Data Processing clusters.
### Additional information
* [Buffer overflow in command line unescaping](https://www.sudo.ws/alerts/unescape_overflow.html)
* [CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit)](https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit)
## 24/12/2020: CVE-2020-25695: Privilege escalation in PostgreSQL
### Description
The [CVE-2020-25695](https://nvd.nist.gov/vuln/detail/CVE-2020-25695) vulnerability was discovered in the PostgreSQL database management system, which allows an attacker having permission to create non-temporary objects to execute arbitrary SQL queries under the identity of a superuser.
### Impact on Yandex Cloud services
All PostgreSQL instances used in Yandex Managed Service for PostgreSQL were [updated](https://www.postgresql.org/about/news/postgresql-131-125-1110-1015-9620-and-9524-released-2111/).
## 19/11/2020: Discontinue support for deprecated TLS protocols {#discontinue-support-for-deprecated-tls}
### Description
To make data transmission more secure, Yandex Cloud recommends that all users switch to technologies that provide encryption via [TLS 1.2](https://tools.ietf.org/html/rfc5246) and higher.
### Impact on Yandex Cloud services
All Yandex Cloud services support TLS 1.2 and higher. Legacy protocols will gradually be discontinued. We recommend that you upgrade your applications to the latest TLS versions in advance.
## 20/09/2020: CVE-2020-1472 (aka Zerologon)
### Description
A Windows Netlogon Remote Protocol vulnerability that allows an unauthenticated attacker with network access permissions to a domain controller to compromise all Active Directory identification services.
Original report from Secura: [Zerologon](https://www.secura.com/whitepapers/zerologon-whitepaper).
Vulnerability description by Microsoft: [CVE-2020-1472](https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1472).
Change management guide from Microsoft: [How to manage the changes in Netlogon secure channel connections associated with CVE-2020-1472](https://support.microsoft.com/ru-ru/help/4557222/how-to-manage-the-changes-in-netlogon-secure-channel-connections-assoc).
### Impact on Yandex Cloud services
OS images available to Yandex Compute Cloud users already contain updates that fix the vulnerability. All VMs created in Yandex Compute Cloud after the issue was reported are protected against the described attack.
### Compensatory measures
In addition to the updates, to restrict access to your domain controller from untrusted networks, use the following network access control systems:
* Windows Firewall or security groups.
* Moving the domain controller behind a NAT gateway.
## 15/06/2020: Special Register Buffer Data Sampling Attack (aka CrossTalk)
### Description
On certain Intel CPU models, VUSec [detected a new attack](https://www.vusec.net/projects/crosstalk/) called Special Register Buffer Data Sampling Attack (or CrossTalk). During this attack, a malicious process can get the results returned by the RDRAND and RDSEED instructions from another process, even when the malicious and legitimate processes run on different physical CPU cores. The attack is assigned the ID [CVE-2020-0543](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-0543).
Report from Intel: [Deep Dive: Special Register Buffer Data Sampling](https://software.intel.com/security-software-guidance/insights/deep-dive-special-register-buffer-data-sampling).
### Impact on Yandex Cloud services
Yandex Cloud uses CPU models that are **not vulnerable to CrossTalk attacks**.
## 28.08.2019: TCP SACK
### Description
Netflix experts found three vulnerabilities in the Linux kernel:
* [CVE-2019-11477](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11477)
* [CVE-2019-11478](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11478)
* [CVE-2019-11479](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11479)
Original report from Netflix: [NFLX-2019-001](https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md).
Vulnerability analysis from Red Hat: [TCP SACK PANIC](https://access.redhat.com/security/vulnerabilities/tcpsack).
### Impact on Yandex Cloud services
* The Yandex Cloud infrastructure was promptly protected and updated.
* The OS images available to Yandex Compute Cloud users were updated as soon as the appropriate fixes became available. Therefore, the new VMs created in Yandex Compute Cloud are not vulnerable to those vulnerabilities.
## 19.08.2019: Some Yandex Object Storage domains are included in the Public Suffix List
### Description
List of domains included in Public Suffix List:
* yandexcloud.net
* storage.yandexcloud.net
* website.yandexcloud.net
Domains in the Public Suffix List get the properties of top-level domains, such as .ru or .com:
* Browsers will not save the cookies set for the listed domains.
* Browsers will not allow you to change the page's `Origin` request header to root domains.
### Impact on Yandex Cloud services
These changes will improve security for Yandex Cloud users.