GitHub Security Lab researchers find vulnerabilities in key, widely-used open source projects. We then coordinate the disclosure of those vulnerabilities to security teams at those projects. We only publish vulnerabilities here after they’ve been announced by the affected projects' development teams and patches are available. See our disclosure policy below for more information.
118 CVEs discovered by GitHub Security Lab
Multiple int-to-bool casting vulnerabilities, leading to heap overflow
An integer overflow when reading large crash dumps (> 4GB) leads to a heap buffer overflow, which may enable a local attacker to gain code execution in the whoopsie daemon. This could enable an attacker to read crash reports belonging to other users and thereby gain access to privileged information.
Local privilege escalation due to TOCTOU in crash reporter
If an attacker is able to control the parameters of a call to the PHP function scrypt_enc, then they can trigger an integer overflow leading to a heap corruption, thereby possibly achieving code execution. There is no risk of exploitation if the server-side PHP code does not pass untrusted parameters to scrypt_enc.
Denial of service (uncaught std::bad_alloc exception) when reading a crafted PNG image file
A PngChunk::parseChunkContent uncontrolled memory allocation in Exiv2 through 0.27.1 allows an attacker to cause a denial of service (crash due to an std::bad_alloc exception) via a crafted PNG image file.
Denial of service (integer overflow leading to an out-of-bounds read) when reading a craft CRW image file
An integer overflow in Exiv2 through 0.27.1 allows an attacker to cause a denial of service (SIGSEGV) via a crafted PNG image file, because PngImage::readMetadata mishandles a zero value for iccOffset.
Denial of service (integer overflow leading to a very large allocation) when reading a crafted PNG image file
An integer overflow in Exiv2 through 0.27.1 allows an attacker to cause a denial of service (SIGSEGV) via a crafted PNG image file, because PngImage::readMetadata mishandles a chunkLength - iccOffset subtraction.
Remote denial of service (null pointer dereference) when connecting to a malicious HTTP server
A WebPImage::decodeChunks integer overflow in Exiv2 through 0.27.1 allows an attacker to cause a denial of service (large heap allocation followed by a very long running loop) via a crafted WEBP image file.
In Libav 12.3, a denial of service in the subtitle decoder allows attackers to hog the CPU via a crafted video file in Matroska format, because srt_to_ass in libavcodec/srtdec.c has a complex format argument to sscanf.
FFmpeg denial of service due to use of sscanf in inner loop in htmlsubtitles.c (close brace scanning)
A denial of service in the subtitle decoder in FFmpeg 4.1 allows attackers to hog the CPU via a crafted video file in Matroska format, because handle_open_brace in libavcodec/htmlsubtitles.c has a complex format argument to sscanf.
Denial of service due to use of sscanf in inner loop in htmlsubtitles.c (close tag scanning)
In FFmpeg 4.1, a denial of service in the subtitle decoder allows attackers to hog the CPU via a crafted video file in Matroska format, because ff_htmlmarkup_to_ass in libavcodec/htmlsubtitles.c has a complex format argument to sscanf.
Stack buffer overflow in libav (snprintf overflow)
A stack-based buffer overflow in the subtitle decoder in Libav 12.3 allows attackers to corrupt the stack via a crafted video file in Matroska format, because srt_to_ass in libavcodec/srtdec.c misuses snprintf.
Denial of service due to quadratic call to strstr in srtdec.c (close tag scanning)
An attacker with permissions to manage podcasts can read (and publish) arbitrary files from the server hosting an Airsonic media streamer by uploading a specially-crafted XML podcast specification containing one or more XML external entities.
Ansible fetch module has a path traversal vulnerability which allows copying and overwriting files outside of the specified destination in the local ansible controller host, by not restricting an absolute path.
SPARQL Injection in VIVO Vitro v1.10.0 allows a remote attacker to execute arbitrary SPARQL via the uri parameter, leading to a regular expression denial of service (ReDoS), as demonstrated by crafted use of FILTER%20regex in a /individual?uri= request.
Command Injection Vulnerability in kill-port Package
This vulnerability affects a range of Apple products. If the kernel's packet-mangler is enabled, it allows an attacker to remotely trigger an infinite loop in the kernel, thereby preventing the device from accessing the internet and hogging one of its CPU cores.
Using a specially-crafted PS or PDF file, an attacker can corrupt memory when the file is opened or processed by Ghostscript. This is caused by insufficient type checking, leading to type confusion, which could potentially be exploited to execute code even when Ghostscript is running in sandbox mode (using the '-dSAFER' option).
RCE vulnerability in Ghostscript when opening or processing PS and PDF files
Using a specially-crafted PS or PDF file, an attacker can execute arbitrary shell commands when the file is opened or processed by Ghostscript, even when Ghostscript is running in sandbox mode (using the '-dSAFER' option).
RCE vulnerability in Ghostscript when opening or processing PS and PDF files
Using a specially-crafted PS or PDF file, an attacker can execute arbitrary code when the file is opened or processed by Ghostscript, even when Ghostscript is running in sandbox mode (using the '-dSAFER' option). This is caused by insufficient type checking, leading to type confusion and memory corruption, which can be exploited to execute code.
Prototype pollution in cached-path-relative package
A remote code execution vulnerability exists in the way the Icecast streaming media server copies HTTP headers from a user request when preparing a request to send to an authentication server. The vulnerability could allow an attacker to craft special HTTP headers that corrupt memory and execute arbitrary code on the server.
Kernel crash caused by buffer overflow in Apple's ICMP packet-handling code
A remote code execution vulnerability exists in the way that the Chakra scripting engine handles objects in memory in Microsoft Edge. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker who successfully exploited the vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
An issue was discovered in certain Apple products. iOS before 11.4 is affected. macOS before 10.13.5 is affected. tvOS before 11.4 is affected. watchOS before 4.3.1 is affected. The issue involves pktmnglr_ipfilter_input in com.apple.packet-mangler in the "Kernel" component. It allows attackers to execute arbitrary code in a privileged context or cause a denial of service (integer overflow and stack-based buffer overflow) via a crafted app.
When deserializing subclasses of AbstractDocument, the class takes a string from the inputStream as the class name. This name is then used to call the no-arg constructor of the class. This vulnerability was fixed by checking the class type before calling newInstance in deserialization.
Buffer underflow vulnerability in strongSwan VPN charon server
The Apache Ignite serialization mechanism does not have a list of classes allowed for serialization/deserialization, which makes it possible to run arbitrary code when 3rd party vulnerable classes are present in the Ignite classpath. An attacker can exploit the vulnerability by sending a specially crafted serialized object to one of the deserialization endpoints of some Ignite components: discovery SPI, Ignite persistence, Memcached endpoint and socket steamer.
Negative integer overflows in Apple's NFS Diskless Boot
The TcpServer within the Geode locator opens a network port that deserializes data. If an unprivileged user gains access to the Geode locator, they may be able to cause remote code execution if certain classes are present on the classpath.
RCE in Apache Geode due to unsafe deserialization of application objects
The Geode server stores application objects in serialized form. Certain cluster operations and API invocations cause these objects to be deserialized. An user with DATA:WRITE access to the cluster may be able to cause remote code execution if certain classes are present on the classpath.
An issue was discovered in certain Apple products. iOS before 11.2 is affected. macOS before 10.13.2 is affected. tvOS before 11.2 is affected. watchOS before 4.2 is affected. The issue involves the "Kernel" component. It allows attackers to execute arbitrary code in a privileged context or cause a denial of service (memory corruption) via a crafted app.
The Hotrod client in Infinispan would unsafely read deserialized data on information from the cache. An authenticated attacker could inject a malicious object into the data cache and attain deserialization on the client, and possibly conduct further attacks.
Versions of Etherpad Lite before the release of v1.16.3 fail to sanitize the name of the JSONP callback function used in the HTTP API. This allows remote attackers to bypass intended access restrictions, making the HTTP API vulnerable to a reflected file download (RFD) attack.
XSS in Etherpad Lite before v1.6.3 via window.location.href
This vulnerability in Apache Hadoop allows a cluster user to expose private files owned by the user running the MapReduce job history server process. The malicious user can construct a configuration file containing XML directives that reference sensitive files on the MapReduce job history server host.
Apache Camel's Castor unmarshalling operation is vulnerable to RCE attacks
The XmlUtils class in jbpmmigration performed expansion of external parameter entities while parsing XML files. A remote attacker could use this flaw to read files accessible to the user running the application server and, potentially, perform other more advanced XML external entity (XXE) attacks.
Restlet Framework before 2.3.12 allows remote attackers to access arbitrary files via a crafted REST API HTTP request that conducts an XXE attack, because only general external entities (not parameter external entities) are properly considered. This is related to XmlRepresentation, DOMRepresentation, SaxRepresentation, and JacksonRepresentation.
XML External Entity expansion vulnerability in Restlet
In Pivotal Spring AMQP versions before 1.7.4, 1.6.11, and 1.5.7, an org.springframework.amqp.core.Message may be unsafely deserialized when being converted into a string. A malicious payload could be crafted to exploit this and enable a remote code execution attack.
RCE vulnerability in the Apache Struts REST plugin
In vulnerable versions of Apache Struts, the REST plugin uses an XStreamHandler with an instance of XStream to deserialize data without applying any type filtering. This makes it possible to provide an XML payload that will allow remote code execution (RCE) when it is deserialized.
The Swagger code generator and parser use the SnakeYaml library to process OpenAPI/Swagger specifications written in YAML. They invoke SnakeYaml insecurely which allows an attacker to parse a malicious specification and execute arbitrary code.
Unsafe deserialization in Apache Spark launcher API
In all versions of Apache Spark from 1.16.0 to 2.1.1, the launcher API performs unsafe deserialization of data received by its socket. This makes applications launched programmatically using the launcher API potentially vulnerable to arbitrary code execution by an attacker with access to any user account on the local machine. The attacker would be able to execute code as the user that ran the Spark application. It does not affect apps run by spark-submit or spark-shell.
Microsoft Edge is prone to a remote memory-corruption vulnerability. Attackers can exploit this issue by enticing an unsuspecting user to view a specially crafted web page. This could allow the attacker to execute arbitrary code in the context of the currently logged-in user. Failed attacks will cause denial of service conditions.
Last updated: November 4th, 2019
The GitHub Security Lab research team is dedicated to working closely
with the open source community
and with projects that are affected by a vulnerability,
in order to protect users and ensure a coordinated disclosure.
When a vulnerability is identified in a project,
we will report it by contacting the publicly-listed
security contact for the project if one exists;
otherwise we will attempt to contact the project maintainers directly.
If the project team responds and agrees the issue is security-critical,
we will work with the project security team or maintainers
to communicate the vulnerability in detail,
and agree on the process for public disclosure.
Responsibility for developing and releasing a patch
lies firmly with the project team,
though we aim to facilitate this
by providing detailed information about the vulnerability.
Our disclosure deadline for publicly disclosing a vulnerability is:
90 days after the first report to the project team,
or 30 days after a project maintainer has published a code change
that publicly addresses the vulnerability, whichever is sooner.
The maintainers of an open source project were notified by us
of a security vulnerability in their project on July 1.
Public disclosure needs to have taken place by September 29
(90 days after the initial report).
On July 20, one of the project’s developers pushes a commit
that addresses the vulnerability to a publicly accessible repository.
The deadline for public disclosure is now August 19 (30 days after the commit).
Until this disclosure deadline lapses, we are available to coordinate
with the project team in preparing a public announcement,
providing that appropriate credit is given to the GitHub Security Lab,
and the researcher(s) who discovered the vulnerability.
Prior to the public disclosure, we expect the project team
to arrange the assignment of a CVE through the usual channels.
For some vulnerabilities we may choose to publish a blog post
on the GitHub Security Lab as part of the public announcement and disclosure.
We will not release a proof-of-concept exploit
at the same time as the initial public announcement and disclosure,
unless otherwise agreed with the project team.
If the disclosure deadline lapses without any announcement
being made by the project team,
we will disclose the vulnerability to the public unless agreed otherwise.
In the event that the project team does not respond or agree
that a reported vulnerability is a genuine security issue,
then we may decide to request a CVE ourselves
and subsequently publicly disclose the issue at any time,
not subject to the above disclosure deadlines.
Please contact us at email@example.com
if you have any questions about our disclosure policy or our security research.