An exploitable code execution vulnerability exists in the XPM image rendering function of SDL2image 2.0.4. A specially crafted XPM image can cause an integer overflow in the colorhash function, allocating too small of a buffer. This buffer can then be written out of bounds, resulting in a heap overflow, ultimately ending in code execution. An attacker can display a specially crafted image to trigger this vulnerability.
An exploitable code execution vulnerability exists in the XPM image rendering functionality of SDL2image 2.0.4. A specially crafted XPM image can cause an integer overflow, allocating too small of a buffer. This buffer can then be written out of bounds resulting in a heap overflow, ultimately ending in code execution. An attacker can display a specially crafted image to trigger this vulnerability.
An exploitable code execution vulnerability exists in the XCF image rendering functionality of SDL2image 2.0.4. A specially crafted XCF image can cause a heap overflow, resulting in code execution. An attacker can display a specially crafted image to trigger this vulnerability.
An exploitable code execution vulnerability exists in the PCX image-rendering functionality of SDL2image 2.0.4. A specially crafted PCX image can cause a heap overflow, resulting in code execution. An attacker can display a specially crafted image to trigger this vulnerability.
In PuTTY versions before 0.71 on Windows, local attackers could hijack the application by putting a malicious help file in the same directory as the executable.
A vulnerability was found in SQLAlchemy 1.2.17. An SQL Injection when the groupby parameter can be controlled.
References: https://github.com/no-security/sqlalchemytest
A race condition flaw was found in the Extensions component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=918861
External References:
https://chromereleases.googleblog.com/2019/03/stable-channel-update-for-desktop12.html
In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to remote code execution when executed with the -u flag and the import path of a malicious Go package, or a package that imports it directly or indirectly. Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Moduleawaregoget). Using custom domains, it's possible to arrange things so that a Git repository is cloned to a folder named ".git" by using a vanity import path that ends with "/.git". If the Git repository root contains a "HEAD" file, a "config" file, an "objects" directory, a "refs" directory, with some work to ensure the proper ordering of operations, "go get -u" can be tricked into considering the parent directory as a repository root, and running Git commands on it. That will use the "config" file in the original Git repository root for its configuration, and if that config file contains malicious commands, they will execute on the system running "go get -u".
In Go before 1.10.6 and 1.11.x before 1.11.3, the "go get" command is vulnerable to directory traversal when executed with the import path of a malicious Go package which contains curly braces (both '{' and '}' characters). Specifically, it is only vulnerable in GOPATH mode, but not in module mode (the distinction is documented at https://golang.org/cmd/go/#hdr-Moduleawaregoget). The attacker can cause an arbitrary filesystem write, which can lead to code execution.