Publicus/cvefixes-security-ir-graphrag huggingface dataset:
CVE-2022-2596: Inefficient Regular Expression Complexity (CWE-1333)
value: Inefficient Regular Expression Complexity in GitHub repository node-fetch/node-fetch prior to 3.2.10.


CWE description: The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles.
CVSS v3 base score: 5.9
Published: 2022-08-01T15:15Z
Repository: https://github.com/node-fetch/node-fetch
Language: JavaScript
Files changed: src/utils/referrer.js
Commit date: 2022-07-31 10:01:29 +0200
Commit message: fix: ReDoS referrer (#1611)

* fix ReDoS referrer

* Update src/utils/referrer.js

Eliminate regex and use string matcher

Co-authored-by: Linus Unnebäck <linus@folkdatorn.se>

Co-authored-by: Khang. Võ Vĩ <khangvv@vng.com.vn>
Co-authored-by: Linus Unnebäck <linus@folkdatorn.se>
Diff: diff --git a/src/utils/referrer.js b/src/utils/referrer.js
index c8c6686..6741f2f 100644
--- a/src/utils/referrer.js
+++ b/src/utils/referrer.js
@@ -117,11 +117,11 @@ export function isOriginPotentiallyTrustworthy(url) {
 	}
 
 	// 5. If origin's host component is "localhost" or falls within ".localhost", and the user agent conforms to the name resolution rules in [let-localhost-be-localhost], return "Potentially Trustworthy".
 	// We are returning FALSE here because we cannot ensure conformance to
 	// let-localhost-be-loalhost (https://tools.ietf.org/html/draft-west-let-localhost-be-localhost)
-	if (/^(.+\.)*localhost$/.test(url.host)) {
+	if (url.host === 'localhost' || url.host.endsWith('.localhost')) {
 		return false;
 	}
 
 	// 6. If origin's scheme component is file, return "Potentially Trustworthy".
 	if (url.protocol === 'file:') {

Vulnerable code: 	if (/^(.+\.)*localhost$/.test(url.host)) {
Fixed code: 	if (url.host === 'localhost' || url.host.endsWith('.localhost')) {
CVE-2020-36324: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') (CWE-79)
value: Wikimedia Quarry analytics-quarry-web before 2020-12-15 allows Reflected XSS because app.py does not explicitly set the application/json content type.
CWE description: The product does not neutralize or incorrectly neutralizes user-controllable input before it is placed in output that is used as a web page that is served to other users.
CVSS v3 base score: 6.1
Published: 2021-04-21T20:15Z
Repository: https://github.com/wikimedia/analytics-quarry-web
Language: Python
Files changed: quarry/web/app.py
Commit date: 2020-12-15 17:37:39 +0000
Commit message: SECURITY: Set correct Mime Type on /api/preferences

Prevents a Reflected Cross-Site scripting (XSS) vulnerability

Bug: T270195
Change-Id: I04bf53d2a939da369e54e91899615a3ffc3e5caf

Diff: diff --git a/quarry/web/app.py b/quarry/web/app.py
index 13251eb..845a60f 100644
--- a/quarry/web/app.py
+++ b/quarry/web/app.py
@@ -396,21 +396,30 @@ def output_explain(connection_id):
 def pref_get(key):
     if get_user() is None:
         return "Authentication required", 401
 
     if key in get_preferences():
-        return Response(json.dumps({'key': key, 'value': get_preferences()[key]}))
+        return Response(
+            json.dumps({'key': key, 'value': get_preferences()[key]}),
+            mimetype='application/json'
+        )
     else:
-        return Response(json.dumps({'key': key, 'error': 'novalue'}))
+        return Response(
+            json.dumps({'key': key, 'error': 'novalue'}),
+            mimetype='application/json'
+        )
 
 
 @app.route("/api/preferences/set/<key>/<value>")
 def pref_set(key, value):
     if get_user() is None:
         return "Authentication required", 401
 
     get_preferences()[key] = (None if value == 'null' else value)
-    return Response(json.dumps({'key': key, 'success': ''})), 201
+    return Response(
+        json.dumps({'key': key, 'success': ''}),
+        mimetype='application/json'
+    ), 201
 
 
 if __name__ == '__main__':
     app.run(port=5000, host="0.0.0.0")

Vulnerable code:         return Response(json.dumps({'key': key, 'value': get_preferences()[key]}))
        return Response(json.dumps({'key': key, 'error': 'novalue'}))
    return Response(json.dumps({'key': key, 'success': ''})), 201
Fixed code:         return Response(
            json.dumps({'key': key, 'value': get_preferences()[key]}),
            mimetype='application/json'
        )
        return Response(
            json.dumps({'key': key, 'error': 'novalue'}),
            mimetype='application/json'
        )
    return Response(
        json.dumps({'key': key, 'success': ''}),
        mimetype='application/json'
    ), 201
CVE-2023-28109: Authorization Bypass Through User-Controlled Key (CWE-639)
value: Play With Docker is a browser-based Docker playground. Versions 0.0.2 and prior are vulnerable to domain hijacking.
Because CORS configuration was not correct, an attacker could use `play-with-docker.com` as an example and set the origin header in an http request as `evil-play-with-docker.com`. The domain would echo in response header, which successfully bypassed the CORS policy and retrieved basic user information. This issue has been fixed in commit ed82247c9ab7990ad76ec2bf1498c2b2830b6f1a. There are no known workarounds.
CWE description: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
CVSS v3 base score: 6.5
Published: 2023-03-16T17:15Z
Repository: https://github.com/play-with-docker/play-with-docker
Language: Go
Files changed: handlers/bootstrap.go
Commit date: 2023-03-02 01:50:08 -0300
Commit message: fix CORS origins to avoid domain hijacking

Signed-off-by: Marcos Lilljedahl <marcosnils@gmail.com>

Diff: diff --git a/handlers/bootstrap.go b/handlers/bootstrap.go
index bfd676c..e898fde 100644
--- a/handlers/bootstrap.go
+++ b/handlers/bootstrap.go
@@ -68,14 +68,14 @@ func Register(extend HandlerExtender) {
 	r := mux.NewRouter()
 	corsRouter := mux.NewRouter()
 
 	corsHandler := gh.CORS(gh.AllowCredentials(), gh.AllowedHeaders([]string{"x-requested-with", "content-type"}), gh.AllowedMethods([]string{"GET", "POST", "HEAD", "DELETE"}), gh.AllowedOriginValidator(func(origin string) bool {
 		if strings.Contains(origin, "localhost") ||
-			strings.HasSuffix(origin, "play-with-docker.com") ||
-			strings.HasSuffix(origin, "play-with-kubernetes.com") ||
-			strings.HasSuffix(origin, "docker.com") ||
-			strings.HasSuffix(origin, "play-with-go.dev") {
+			strings.HasSuffix(origin, ".play-with-docker.com") ||
+			strings.HasSuffix(origin, ".play-with-kubernetes.com") ||
+			strings.HasSuffix(origin, ".docker.com") ||
+			strings.HasSuffix(origin, ".play-with-go.dev") {
 			return true
 		}
 		return false
 	}), gh.AllowedOrigins([]string{}))
 

Vulnerable code: 			strings.HasSuffix(origin, "play-with-docker.com") ||
			strings.HasSuffix(origin, "play-with-kubernetes.com") ||
			strings.HasSuffix(origin, "docker.com") ||
			strings.HasSuffix(origin, "play-with-go.dev") {
Fixed code: 			strings.HasSuffix(origin, ".play-with-docker.com") ||
			strings.HasSuffix(origin, ".play-with-kubernetes.com") ||
			strings.HasSuffix(origin, ".docker.com") ||
			strings.HasSuffix(origin, ".play-with-go.dev") {
CVE-2018-20748: Out-of-bounds Write (CWE-787)
value: LibVNC before 0.9.12 contains multiple heap out-of-bounds write vulnerabilities in libvncclient/rfbproto.c. The fix for CVE-2018-20019 was incomplete.
CWE description: The product writes data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 9.8
Published: 2019-01-30T18:29Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/rfbproto.c
Commit date: 2018-12-29 14:16:58 +0100
Commit message: LibVNCClient: ignore server-sent cut text longer than 1MB

This is in line with how LibVNCServer does it
(28afb6c537dc82ba04d5f245b15ca7205c6dbb9c) and fixes part of #273.

Diff: diff --git a/libvncclient/rfbproto.c b/libvncclient/rfbproto.c
index 4541e0d5..8792dbf6 100644
--- a/libvncclient/rfbproto.c
+++ b/libvncclient/rfbproto.c
@@ -2215,10 +2215,15 @@ HandleRFBServerMessage(rfbClient* client)
 			   sz_rfbServerCutTextMsg - 1))
       return FALSE;
 
     msg.sct.length = rfbClientSwap32IfLE(msg.sct.length);
 
+    if (msg.sct.length > 1<<20) {
+	    rfbClientErr("Ignoring too big cut text length sent by server: %u B > 1 MB\n", (unsigned int)msg.sct.length);
+	    return FALSE;
+    }  
+
     buffer = malloc((uint64_t)msg.sct.length+1);
 
     if (!ReadFromRFBServer(client, buffer, msg.sct.length)) {
       free(buffer);
       return FALSE;

Fixed code:     if (msg.sct.length > 1<<20) {
	    rfbClientErr("Ignoring too big cut text length sent by server: %u B > 1 MB\n", (unsigned int)msg.sct.length);
	    return FALSE;
    }
CVE-2018-20748: Out-of-bounds Write (CWE-787)
value: LibVNC before 0.9.12 contains multiple heap out-of-bounds write vulnerabilities in libvncclient/rfbproto.c. The fix for CVE-2018-20019 was incomplete.
CWE description: The product writes data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 9.8
Published: 2019-01-30T18:29Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/rfbproto.c
Commit date: 2019-01-06 14:20:37 +0100
Commit message: LibVNCClient: fail on server-sent desktop name lengths longer than 1MB

re #273

Diff: diff --git a/libvncclient/rfbproto.c b/libvncclient/rfbproto.c
index e56e778f..6af21a54 100644
--- a/libvncclient/rfbproto.c
+++ b/libvncclient/rfbproto.c
@@ -1222,12 +1222,16 @@ InitialiseRFBConnection(rfbClient* client)
   client->si.format.redMax = rfbClientSwap16IfLE(client->si.format.redMax);
   client->si.format.greenMax = rfbClientSwap16IfLE(client->si.format.greenMax);
   client->si.format.blueMax = rfbClientSwap16IfLE(client->si.format.blueMax);
   client->si.nameLength = rfbClientSwap32IfLE(client->si.nameLength);
 
-  /* To guard against integer wrap-around, si.nameLength is cast to 64 bit */
-  client->desktopName = malloc((uint64_t)client->si.nameLength + 1);
+  if (client->si.nameLength > 1<<20) {
+      rfbClientErr("Too big desktop name length sent by server: %u B > 1 MB\n", (unsigned int)client->si.nameLength);
+      return FALSE;
+  }
+
+  client->desktopName = malloc(client->si.nameLength + 1);
   if (!client->desktopName) {
     rfbClientLog("Error allocating memory for desktop name, %lu bytes\n",
             (unsigned long)client->si.nameLength);
     return FALSE;
   }

Vulnerable code:   /* To guard against integer wrap-around, si.nameLength is cast to 64 bit */
  client->desktopName = malloc((uint64_t)client->si.nameLength + 1);
Fixed code:   if (client->si.nameLength > 1<<20) {
      rfbClientErr("Too big desktop name length sent by server: %u B > 1 MB\n", (unsigned int)client->si.nameLength);
      return FALSE;
  }

  client->desktopName = malloc(client->si.nameLength + 1);
CVE-2018-20748: Out-of-bounds Write (CWE-787)
value: LibVNC before 0.9.12 contains multiple heap out-of-bounds write vulnerabilities in libvncclient/rfbproto.c. The fix for CVE-2018-20019 was incomplete.
CWE description: The product writes data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 9.8
Published: 2019-01-30T18:29Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/rfbproto.c
Commit date: 2019-01-06 14:22:34 +0100
Commit message: LibVNCClient: remove now-useless cast

re #273

Diff: diff --git a/libvncclient/rfbproto.c b/libvncclient/rfbproto.c
index 6af21a54..2f887c32 100644
--- a/libvncclient/rfbproto.c
+++ b/libvncclient/rfbproto.c
@@ -2225,11 +2225,11 @@ HandleRFBServerMessage(rfbClient* client)
     if (msg.sct.length > 1<<20) {
 	    rfbClientErr("Ignoring too big cut text length sent by server: %u B > 1 MB\n", (unsigned int)msg.sct.length);
 	    return FALSE;
     }  
 
-    buffer = malloc((uint64_t)msg.sct.length+1);
+    buffer = malloc(msg.sct.length+1);
 
     if (!ReadFromRFBServer(client, buffer, msg.sct.length)) {
       free(buffer);
       return FALSE;
     }

Vulnerable code:     buffer = malloc((uint64_t)msg.sct.length+1);
Fixed code:     buffer = malloc(msg.sct.length+1);
CVE-2018-20749: Out-of-bounds Write (CWE-787)
value: LibVNC before 0.9.12 contains a heap out-of-bounds write vulnerability in libvncserver/rfbserver.c. The fix for CVE-2018-15127 was incomplete.
CWE description: The product writes data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 9.8
Published: 2019-01-30T18:29Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncserver/rfbserver.c
Commit date: 2019-01-06 15:13:56 +0100
Commit message: Error out in rfbProcessFileTransferReadBuffer if length can not be allocated

re #273

Diff: diff --git a/libvncserver/rfbserver.c b/libvncserver/rfbserver.c
index 6ca511fe..e210a32f 100644
--- a/libvncserver/rfbserver.c
+++ b/libvncserver/rfbserver.c
@@ -1459,15 +1459,25 @@ char *rfbProcessFileTransferReadBuffer(rfbClientPtr cl, uint32_t length)
 {
     char *buffer=NULL;
     int   n=0;
 
     FILEXFER_ALLOWED_OR_CLOSE_AND_RETURN("", cl, NULL);
+
     /*
-    rfbLog("rfbProcessFileTransferReadBuffer(%dlen)\n", length);
+       We later alloc length+1, which might wrap around on 32-bit systems if length equals
+       0XFFFFFFFF, i.e. SIZE_MAX for 32-bit systems. On 64-bit systems, a length of 0XFFFFFFFF
+       will safely be allocated since this check will never trigger and malloc() can digest length+1
+       without problems as length is a uint32_t.
     */
+    if(length == SIZE_MAX) {
+	rfbErr("rfbProcessFileTransferReadBuffer: too big file transfer length requested: %u", (unsigned int)length);
+	rfbCloseClient(cl);
+	return NULL;
+    }
+
     if (length>0) {
-        buffer=malloc((uint64_t)length+1);
+        buffer=malloc((size_t)length+1);
         if (buffer!=NULL) {
             if ((n = rfbReadExact(cl, (char *)buffer, length)) <= 0) {
                 if (n != 0)
                     rfbLogPerror("rfbProcessFileTransferReadBuffer: read");
                 rfbCloseClient(cl);

Vulnerable code:     rfbLog("rfbProcessFileTransferReadBuffer(%dlen)\n", length);
        buffer=malloc((uint64_t)length+1);
Fixed code: 
       We later alloc length+1, which might wrap around on 32-bit systems if length equals
       0XFFFFFFFF, i.e. SIZE_MAX for 32-bit systems. On 64-bit systems, a length of 0XFFFFFFFF
       will safely be allocated since this check will never trigger and malloc() can digest length+1
       without problems as length is a uint32_t.
    if(length == SIZE_MAX) {
	rfbErr("rfbProcessFileTransferReadBuffer: too big file transfer length requested: %u", (unsigned int)length);
	rfbCloseClient(cl);
	return NULL;
    }

        buffer=malloc((size_t)length+1);
CVE-2018-20750: Out-of-bounds Write (CWE-787)
value: LibVNC through 0.9.12 contains a heap out-of-bounds write vulnerability in libvncserver/rfbserver.c. The fix for CVE-2018-15127 was incomplete.
CWE description: The product writes data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 9.8
Published: 2019-01-30T18:29Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncserver/rfbserver.c
Commit date: 2019-01-08 10:00:24 +0100
Commit message: Limit lenght to INT_MAX bytes in rfbProcessFileTransferReadBuffer()

This ammends 15bb719c03cc70f14c36a843dcb16ed69b405707 fix for a heap
out-of-bound write access in rfbProcessFileTransferReadBuffer() when
reading a transfered file content in a server. The former fix did not
work on platforms with a 32-bit int type (expected by rfbReadExact()).

CVE-2018-15127
<https://github.com/LibVNC/libvncserver/issues/243>
<https://github.com/LibVNC/libvncserver/issues/273>

Diff: diff --git a/libvncserver/rfbserver.c b/libvncserver/rfbserver.c
index 7af849063..f2edbeeac 100644
--- a/libvncserver/rfbserver.c
+++ b/libvncserver/rfbserver.c
@@ -86,10 +86,12 @@
 
 /* errno */
 #include <errno.h>
 /* strftime() */
 #include <time.h>
+/* INT_MAX */
+#include <limits.h>
 
 #ifdef LIBVNCSERVER_WITH_WEBSOCKETS
 #include "rfbssl.h"
 #endif
 
@@ -1470,12 +1472,15 @@ char *rfbProcessFileTransferReadBuffer(rfbClientPtr cl, uint32_t length)
     /*
        We later alloc length+1, which might wrap around on 32-bit systems if length equals
        0XFFFFFFFF, i.e. SIZE_MAX for 32-bit systems. On 64-bit systems, a length of 0XFFFFFFFF
        will safely be allocated since this check will never trigger and malloc() can digest length+1
        without problems as length is a uint32_t.
+       We also later pass length to rfbReadExact() that expects a signed int type and
+       that might wrap on platforms with a 32-bit int type if length is bigger
+       than 0X7FFFFFFF.
     */
-    if(length == SIZE_MAX) {
+    if(length == SIZE_MAX || length > INT_MAX) {
 	rfbErr("rfbProcessFileTransferReadBuffer: too big file transfer length requested: %u", (unsigned int)length);
 	rfbCloseClient(cl);
 	return NULL;
     }
 

Vulnerable code:     if(length == SIZE_MAX) {
Fixed code: /* INT_MAX */
#include <limits.h>
       We also later pass length to rfbReadExact() that expects a signed int type and
       that might wrap on platforms with a 32-bit int type if length is bigger
       than 0X7FFFFFFF.
    if(length == SIZE_MAX || length > INT_MAX) {
CVE-2019-15681: Improper Initialization (CWE-665)
value: LibVNC commit before d01e1bb4246323ba6fcee3b82ef1faa9b1dac82a contains a memory leak (CWE-655) in VNC server code, which allow an attacker to read stack memory and can be abused for information disclosure. Combined with another vulnerability, it can be used to leak stack memory and bypass ASLR. This attack appear to be exploitable via network connectivity. These vulnerabilities have been fixed in commit d01e1bb4246323ba6fcee3b82ef1faa9b1dac82a.
CWE description: The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used.
CVSS v3 base score: 7.5
Published: 2019-10-29T19:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncserver/rfbserver.c
Commit date: 2019-08-19 22:32:25 +0200
Commit message: rfbserver: don't leak stack memory to the remote

Thanks go to Pavel Cheremushkin of Kaspersky for reporting.

Diff: diff --git a/libvncserver/rfbserver.c b/libvncserver/rfbserver.c
index 3bacc8917..310e5487e 100644
--- a/libvncserver/rfbserver.c
+++ b/libvncserver/rfbserver.c
@@ -3722,10 +3722,12 @@ rfbSendServerCutText(rfbScreenInfoPtr rfbScreen,char *str, int len)
 {
     rfbClientPtr cl;
     rfbServerCutTextMsg sct;
     rfbClientIteratorPtr iterator;
 
+    memset((char *)&sct, 0, sizeof(sct));
+
     iterator = rfbGetClientIterator(rfbScreen);
     while ((cl = rfbClientIteratorNext(iterator)) != NULL) {
         sct.type = rfbServerCutText;
         sct.length = Swap32IfLE(len);
         LOCK(cl->sendMutex);

Fixed code:     memset((char *)&sct, 0, sizeof(sct));
CVE-2019-20788: Integer Overflow or Wraparound (CWE-190)
value: libvncclient/cursor.c in LibVNCServer through 0.9.12 has a HandleCursorShape integer overflow and heap-based buffer overflow via a large height or width value. NOTE: this may overlap CVE-2019-15690.
CWE description: The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
CVSS v3 base score: 9.8
Published: 2020-04-23T19:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/cursor.c
Commit date: 2019-11-17 17:23:03 +0100
Commit message: libvncclient/cursor: limit width/height input values

Avoids a possible heap overflow reported by Pavel Cheremushkin
<Pavel.Cheremushkin@kaspersky.com>.

re #275

Diff: diff --git a/libvncclient/cursor.c b/libvncclient/cursor.c
index 67f457267..40ffb3b0e 100644
--- a/libvncclient/cursor.c
+++ b/libvncclient/cursor.c
@@ -26,10 +26,12 @@
 
 
 #define OPER_SAVE     0
 #define OPER_RESTORE  1
 
+#define MAX_CURSOR_SIZE 1024
+
 #define RGB24_TO_PIXEL(bpp,r,g,b)                                       \
    ((((uint##bpp##_t)(r) & 0xFF) * client->format.redMax + 127) / 255             \
     << client->format.redShift |                                              \
     (((uint##bpp##_t)(g) & 0xFF) * client->format.greenMax + 127) / 255           \
     << client->format.greenShift |                                            \
@@ -52,10 +54,13 @@ rfbBool HandleCursorShape(rfbClient* client,int xhot, int yhot, int width, int h
   bytesMaskData = bytesPerRow * height;
 
   if (width * height == 0)
     return TRUE;
 
+  if (width >= MAX_CURSOR_SIZE || height >= MAX_CURSOR_SIZE)
+    return FALSE;
+
   /* Allocate memory for pixel data and temporary mask data. */
   if(client->rcSource)
     free(client->rcSource);
 
   client->rcSource = malloc(width * height * bytesPerPixel);

Fixed code: #define MAX_CURSOR_SIZE 1024

  if (width >= MAX_CURSOR_SIZE || height >= MAX_CURSOR_SIZE)
    return FALSE;
CVE-2019-20788: Out-of-bounds Write (CWE-787)
value: libvncclient/cursor.c in LibVNCServer through 0.9.12 has a HandleCursorShape integer overflow and heap-based buffer overflow via a large height or width value. NOTE: this may overlap CVE-2019-15690.
CWE description: The product writes data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 9.8
Published: 2020-04-23T19:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/cursor.c
Commit date: 2019-11-17 17:23:03 +0100
Commit message: libvncclient/cursor: limit width/height input values

Avoids a possible heap overflow reported by Pavel Cheremushkin
<Pavel.Cheremushkin@kaspersky.com>.

re #275

Diff: diff --git a/libvncclient/cursor.c b/libvncclient/cursor.c
index 67f457267..40ffb3b0e 100644
--- a/libvncclient/cursor.c
+++ b/libvncclient/cursor.c
@@ -26,10 +26,12 @@
 
 
 #define OPER_SAVE     0
 #define OPER_RESTORE  1
 
+#define MAX_CURSOR_SIZE 1024
+
 #define RGB24_TO_PIXEL(bpp,r,g,b)                                       \
    ((((uint##bpp##_t)(r) & 0xFF) * client->format.redMax + 127) / 255             \
     << client->format.redShift |                                              \
     (((uint##bpp##_t)(g) & 0xFF) * client->format.greenMax + 127) / 255           \
     << client->format.greenShift |                                            \
@@ -52,10 +54,13 @@ rfbBool HandleCursorShape(rfbClient* client,int xhot, int yhot, int width, int h
   bytesMaskData = bytesPerRow * height;
 
   if (width * height == 0)
     return TRUE;
 
+  if (width >= MAX_CURSOR_SIZE || height >= MAX_CURSOR_SIZE)
+    return FALSE;
+
   /* Allocate memory for pixel data and temporary mask data. */
   if(client->rcSource)
     free(client->rcSource);
 
   client->rcSource = malloc(width * height * bytesPerPixel);

Fixed code: #define MAX_CURSOR_SIZE 1024

  if (width >= MAX_CURSOR_SIZE || height >= MAX_CURSOR_SIZE)
    return FALSE;
CVE-2019-20839: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') (CWE-120)
value: libvncclient/sockets.c in LibVNCServer before 0.9.13 has a buffer overflow via a long socket filename.
CWE description: The product copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.
CVSS v3 base score: 7.5
Published: 2020-06-17T16:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/sockets.c
Commit date: 2019-04-06 20:23:12 +0200
Commit message: libvncclient: bail out if unix socket name would overflow

Closes #291

Diff: diff --git a/libvncclient/sockets.c b/libvncclient/sockets.c
index f042472fa..821f85cad 100644
--- a/libvncclient/sockets.c
+++ b/libvncclient/sockets.c
@@ -459,10 +459,14 @@ ConnectClientToUnixSock(const char *sockFile)
   return -1;
 #else
   int sock;
   struct sockaddr_un addr;
   addr.sun_family = AF_UNIX;
+  if(strlen(sockFile) + 1 > sizeof(addr.sun_path)) {
+      rfbClientErr("ConnectToUnixSock: socket file name too long\n");
+      return -1;
+  }
   strcpy(addr.sun_path, sockFile);
 
   sock = socket(AF_UNIX, SOCK_STREAM, 0);
   if (sock < 0) {
     rfbClientErr("ConnectToUnixSock: socket (%s)\n",strerror(errno));

Fixed code:   if(strlen(sockFile) + 1 > sizeof(addr.sun_path)) {
      rfbClientErr("ConnectToUnixSock: socket file name too long\n");
      return -1;
  }
CVE-2019-20840: Out-of-bounds Write (CWE-787)
value: An issue was discovered in LibVNCServer before 0.9.13. libvncserver/ws_decode.c can lead to a crash because of unaligned accesses in hybiReadAndDecode.
CWE description: The product writes data past the end, or before the beginning, of the intended buffer.
CVSS v3 base score: 7.5
Published: 2020-06-17T16:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncserver/ws_decode.c
Commit date: 2019-05-28 18:30:46 +0200
Commit message: fix crash because of unaligned accesses in hybiReadAndDecode()

Diff: diff --git a/libvncserver/ws_decode.c b/libvncserver/ws_decode.c
index 441ebc73b..10c44d194 100644
--- a/libvncserver/ws_decode.c
+++ b/libvncserver/ws_decode.c
@@ -325,11 +325,10 @@ hybiReadAndDecode(ws_ctx_t *wsctx, char *dst, int len, int *sockRet, int nInBuf)
   int toReturn; /* number of data bytes to return */
   int toDecode; /* number of bytes to decode starting at wsctx->writePos */
   int bufsize;
   int nextRead;
   unsigned char *data;
-  uint32_t *data32;
 
   /* if data was carried over, copy to start of buffer */
   memcpy(wsctx->writePos, wsctx->carryBuf, wsctx->carrylen);
   wsctx->writePos += wsctx->carrylen;
 
@@ -381,14 +380,16 @@ hybiReadAndDecode(ws_ctx_t *wsctx, char *dst, int len, int *sockRet, int nInBuf)
   }
 
   /* for a possible base64 decoding, we decode multiples of 4 bytes until
    * the whole frame is received and carry over any remaining bytes in the carry buf*/
   data = (unsigned char *)(wsctx->writePos - toDecode);
-  data32= (uint32_t *)data;
 
   for (i = 0; i < (toDecode >> 2); i++) {
-    data32[i] ^= wsctx->header.mask.u;
+    uint32_t tmp;
+    memcpy(&tmp, data + i * sizeof(tmp), sizeof(tmp));
+    tmp ^= wsctx->header.mask.u;
+    memcpy(data + i * sizeof(tmp), &tmp, sizeof(tmp));
   }
   ws_dbg("mask decoding; i=%d toDecode=%d\n", i, toDecode);
 
   if (wsctx->hybiDecodeState == WS_HYBI_STATE_FRAME_COMPLETE) {
     /* process the remaining bytes (if any) */

Vulnerable code:   uint32_t *data32;
  data32= (uint32_t *)data;
    data32[i] ^= wsctx->header.mask.u;
Fixed code:     uint32_t tmp;
    memcpy(&tmp, data + i * sizeof(tmp), sizeof(tmp));
    tmp ^= wsctx->header.mask.u;
    memcpy(data + i * sizeof(tmp), &tmp, sizeof(tmp));
CVE-2020-14396: NULL Pointer Dereference (CWE-476)
value: An issue was discovered in LibVNCServer before 0.9.13. libvncclient/tls_openssl.c has a NULL pointer dereference.
CWE description: The product dereferences a pointer that it expects to be valid but is NULL.
CVSS v3 base score: 7.5
Published: 2020-06-17T16:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/tls_openssl.c
Commit date: 2020-03-06 17:37:57 +0100
Commit message: libvncclient/tls_openssl: do not deref a NULL pointer

Happens in anonTLS mode where cred is NULL.

re #347

Diff: diff --git a/libvncclient/tls_openssl.c b/libvncclient/tls_openssl.c
index c9b2647c5..fcef1bc3e 100644
--- a/libvncclient/tls_openssl.c
+++ b/libvncclient/tls_openssl.c
@@ -266,11 +266,11 @@ open_ssl_connection (rfbClient *client, int sockfd, rfbBool anonTLS, rfbCredenti
 {
   SSL_CTX *ssl_ctx = NULL;
   SSL *ssl = NULL;
   int n, finished = 0;
   X509_VERIFY_PARAM *param;
-  uint8_t verify_crls = cred->x509Credential.x509CrlVerifyMode;
+  uint8_t verify_crls;
 
   if (!(ssl_ctx = SSL_CTX_new(SSLv23_client_method())))
   {
     rfbClientLog("Could not create new SSL context.\n");
     return NULL;
@@ -279,10 +279,11 @@ open_ssl_connection (rfbClient *client, int sockfd, rfbBool anonTLS, rfbCredenti
   param = X509_VERIFY_PARAM_new();
 
   /* Setup verification if not anonymous */
   if (!anonTLS)
   {
+    verify_crls = cred->x509Credential.x509CrlVerifyMode;
     if (cred->x509Credential.x509CACertFile)
     {
       if (!SSL_CTX_load_verify_locations(ssl_ctx, cred->x509Credential.x509CACertFile, NULL))
       {
         rfbClientLog("Failed to load CA certificate from %s.\n",

Vulnerable code:   uint8_t verify_crls = cred->x509Credential.x509CrlVerifyMode;
Fixed code:   uint8_t verify_crls;
    verify_crls = cred->x509Credential.x509CrlVerifyMode;
CVE-2020-14399: Other (NVD-CWE-Other)
value: An issue was discovered in LibVNCServer before 0.9.13. Byte-aligned data is accessed through uint32_t pointers in libvncclient/rfbproto.c. NOTE: there is reportedly "no trust boundary crossed.
CWE description: NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
CVSS v3 base score: 7.5
Published: 2020-06-17T16:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/rfbproto.c
Commit date: 2020-05-28 08:47:11 +0200
Commit message: libvncclient: fix pointer aliasing/alignment issue

Accessing byte-aligned data through uint32_t pointers can cause crashes
on some platforms or reduce the performance. Therefore ensure a proper
stack alignment.

Diff: diff --git a/libvncclient/rfbproto.c b/libvncclient/rfbproto.c
index cd2a297ed..6f6d67049 100644
--- a/libvncclient/rfbproto.c
+++ b/libvncclient/rfbproto.c
@@ -1149,14 +1149,17 @@ InitialiseRFBConnection(rfbClient* client)
 
 rfbBool
 SetFormatAndEncodings(rfbClient* client)
 {
   rfbSetPixelFormatMsg spf;
-  char buf[sz_rfbSetEncodingsMsg + MAX_ENCODINGS * 4];
+  union {
+    char bytes[sz_rfbSetEncodingsMsg + MAX_ENCODINGS*4];
+    rfbSetEncodingsMsg msg;
+  } buf;
 
-  rfbSetEncodingsMsg *se = (rfbSetEncodingsMsg *)buf;
-  uint32_t *encs = (uint32_t *)(&buf[sz_rfbSetEncodingsMsg]);
+  rfbSetEncodingsMsg *se = &buf.msg;
+  uint32_t *encs = (uint32_t *)(&buf.bytes[sz_rfbSetEncodingsMsg]);
   int len = 0;
   rfbBool requestCompressLevel = FALSE;
   rfbBool requestQualityLevel = FALSE;
   rfbBool requestLastRectEncoding = FALSE;
   rfbClientProtocolExtension* e;
@@ -1352,11 +1355,11 @@ SetFormatAndEncodings(rfbClient* client)
 
   len = sz_rfbSetEncodingsMsg + se->nEncodings * 4;
 
   se->nEncodings = rfbClientSwap16IfLE(se->nEncodings);
 
-  if (!WriteToRFBServer(client, buf, len)) return FALSE;
+  if (!WriteToRFBServer(client, buf.bytes, len)) return FALSE;
 
   return TRUE;
 }
 
 

Vulnerable code:   char buf[sz_rfbSetEncodingsMsg + MAX_ENCODINGS * 4];
  rfbSetEncodingsMsg *se = (rfbSetEncodingsMsg *)buf;
  uint32_t *encs = (uint32_t *)(&buf[sz_rfbSetEncodingsMsg]);
  if (!WriteToRFBServer(client, buf, len)) return FALSE;
Fixed code:   union {
    char bytes[sz_rfbSetEncodingsMsg + MAX_ENCODINGS*4];
    rfbSetEncodingsMsg msg;
  } buf;
  rfbSetEncodingsMsg *se = &buf.msg;
  uint32_t *encs = (uint32_t *)(&buf.bytes[sz_rfbSetEncodingsMsg]);
  if (!WriteToRFBServer(client, buf.bytes, len)) return FALSE;
CVE-2020-14400: Other (NVD-CWE-Other)
value: An issue was discovered in LibVNCServer before 0.9.13. Byte-aligned data is accessed through uint16_t pointers in libvncserver/translate.c. NOTE: Third parties do not consider this to be a vulnerability as there is no known path of exploitation or cross of a trust boundary
CWE description: NVD is only using a subset of CWE for mapping instead of the entire CWE, and the weakness type is not covered by that subset.
CVSS v3 base score: 7.5
Published: 2020-06-17T16:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncserver/translate.c
Commit date: 2020-05-28 08:47:11 +0200
Commit message: libvncserver: fix pointer aliasing/alignment issue

Accessing byte-aligned data through uint16_t pointers can cause crashes
on some platforms or reduce the performance. Therefore ensure a proper
stack alignment.

Diff: diff --git a/libvncserver/translate.c b/libvncserver/translate.c
index 7c341c2a2..7e6d3d8e0 100644
--- a/libvncserver/translate.c
+++ b/libvncserver/translate.c
@@ -358,13 +358,16 @@ rfbSetTranslateFunction(rfbClientPtr cl)
  */
 
 static rfbBool
 rfbSetClientColourMapBGR233(rfbClientPtr cl)
 {
-    char buf[sz_rfbSetColourMapEntriesMsg + 256 * 3 * 2];
-    rfbSetColourMapEntriesMsg *scme = (rfbSetColourMapEntriesMsg *)buf;
-    uint16_t *rgb = (uint16_t *)(&buf[sz_rfbSetColourMapEntriesMsg]);
+    union {
+        char bytes[sz_rfbSetColourMapEntriesMsg + 256 * 3 * 2];
+        rfbSetColourMapEntriesMsg msg;
+    } buf;
+    rfbSetColourMapEntriesMsg *scme = &buf.msg;
+    uint16_t *rgb = (uint16_t *)(&buf.bytes[sz_rfbSetColourMapEntriesMsg]);
     int i, len;
     int r, g, b;
 
     if (cl->format.bitsPerPixel != 8 ) {
         rfbErr("%s: client not 8 bits per pixel\n",
@@ -392,11 +395,11 @@ rfbSetClientColourMapBGR233(rfbClientPtr cl)
         }
     }
 
     len += 256 * 3 * 2;
 
-    if (rfbWriteExact(cl, buf, len) < 0) {
+    if (rfbWriteExact(cl, buf.bytes, len) < 0) {
         rfbLogPerror("rfbSetClientColourMapBGR233: write");
         rfbCloseClient(cl);
         return FALSE;
     }
     return TRUE;

Vulnerable code:     char buf[sz_rfbSetColourMapEntriesMsg + 256 * 3 * 2];
    rfbSetColourMapEntriesMsg *scme = (rfbSetColourMapEntriesMsg *)buf;
    uint16_t *rgb = (uint16_t *)(&buf[sz_rfbSetColourMapEntriesMsg]);
    if (rfbWriteExact(cl, buf, len) < 0) {
Fixed code:     union {
        char bytes[sz_rfbSetColourMapEntriesMsg + 256 * 3 * 2];
        rfbSetColourMapEntriesMsg msg;
    } buf;
    rfbSetColourMapEntriesMsg *scme = &buf.msg;
    uint16_t *rgb = (uint16_t *)(&buf.bytes[sz_rfbSetColourMapEntriesMsg]);
    if (rfbWriteExact(cl, buf.bytes, len) < 0) {
CVE-2020-14401: Integer Overflow or Wraparound (CWE-190)
value: An issue was discovered in LibVNCServer before 0.9.13. libvncserver/scale.c has a pixel_value integer overflow.
CWE description: The product performs a calculation that can
         produce an integer overflow or wraparound when the logic
         assumes that the resulting value will always be larger than
         the original value. This occurs when an integer value is
         incremented to a value that is too large to store in the
         associated representation. When this occurs, the value may
         become a very small or negative number.
CVSS v3 base score: 6.5
Published: 2020-06-17T16:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncserver/scale.c
Commit date: 2020-05-28 08:53:32 +0200
Commit message: libvncserver: scale: cast to 64 bit before shifting

Since pixel_value is 64 bit the data type of the shift operand should
be 64 bit too to prevent integer overflows.

Diff: diff --git a/libvncserver/scale.c b/libvncserver/scale.c
index a5cdf2baa..39ccb473d 100644
--- a/libvncserver/scale.c
+++ b/libvncserver/scale.c
@@ -208,11 +208,11 @@ void rfbScaledScreenUpdateRect(rfbScreenInfoPtr screen, rfbScreenInfoPtr ptr, in
              case 2: pixel_value = *((unsigned short *)srcptr2); break;
              case 1: pixel_value = *((unsigned char *)srcptr2);  break;
              default:
                /* fixme: endianness problem? */
                for (z = 0; z < bytesPerPixel; z++)
-                 pixel_value += (srcptr2[z] << (8 * z));
+                 pixel_value += ((unsigned long)srcptr2[z] << (8 * z));
                 break;
               }
               /*
               srcptr2 += bytesPerPixel;
               */

Vulnerable code:                  pixel_value += (srcptr2[z] << (8 * z));
Fixed code:                  pixel_value += ((unsigned long)srcptr2[z] << (8 * z));
CVE-2020-14405: Allocation of Resources Without Limits or Throttling (CWE-770)
value: An issue was discovered in LibVNCServer before 0.9.13. libvncclient/rfbproto.c does not limit TextChat size.
CWE description: The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor.
CVSS v3 base score: 6.5
Published: 2020-06-17T16:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/rfbproto.c
Commit date: 2020-04-10 19:07:12 +0200
Commit message: libvncclient/rfbproto: limit max textchat size

Addresses GitHub Security Lab (GHSL) Vulnerability Report
`GHSL-2020-063`.

Re #275

Diff: diff --git a/libvncclient/rfbproto.c b/libvncclient/rfbproto.c
index a54c1e67c..26430c77e 100644
--- a/libvncclient/rfbproto.c
+++ b/libvncclient/rfbproto.c
@@ -63,10 +63,11 @@
 #else
 #include "minilzo.h"
 #endif
 #include "tls.h"
 
+#define MAX_TEXTCHAT_SIZE 10485760 /* 10MB */
 
 /*
  * rfbClientLog prints a time-stamped message to the log file (stderr).
  */
 
@@ -2157,10 +2158,12 @@ HandleRFBServerMessage(rfbClient* client)
           rfbClientLog("Received TextChat Finished\n");
          if (client->HandleTextChat!=NULL)
               client->HandleTextChat(client, (int)rfbTextChatFinished, NULL);
           break;
       default:
+	  if(msg.tc.length > MAX_TEXTCHAT_SIZE)
+	      return FALSE;
           buffer=malloc(msg.tc.length+1);
           if (!ReadFromRFBServer(client, buffer, msg.tc.length))
           {
               free(buffer);
               return FALSE;

Fixed code: #define MAX_TEXTCHAT_SIZE 10485760 /* 10MB */
	  if(msg.tc.length > MAX_TEXTCHAT_SIZE)
	      return FALSE;
CVE-2020-29260: Uncontrolled Resource Consumption (CWE-400)
value: libvncclient v0.9.13 was discovered to contain a memory leak via the function rfbClientCleanup().
CWE description: The product does not properly control the allocation and maintenance of a limited resource, thereby enabling an actor to influence the amount of resources consumed, eventually leading to the exhaustion of available resources.
CVSS v3 base score: 7.5
Published: 2022-09-02T23:15Z
Repository: https://github.com/LibVNC/libvncserver
Language: C
Files changed: libvncclient/vncviewer.c
Commit date: 2020-11-21 12:52:31 +0100
Commit message: libvncclient: free vncRec memory in rfbClientCleanup()

Otherwise we leak memory. Spotted by Ramin Farajpour Cami
<ramin.blackhat@gmail.com>, thanks!

Diff: diff --git a/libvncclient/vncviewer.c b/libvncclient/vncviewer.c
index d6b91f02b..0a1bdcf6a 100644
--- a/libvncclient/vncviewer.c
+++ b/libvncclient/vncviewer.c
@@ -532,10 +532,12 @@ void rfbClientCleanup(rfbClient* client) {
     rfbClientData* next = client->clientData->next;
     free(client->clientData);
     client->clientData = next;
   }
 
+  free(client->vncRec);
+
   if (client->sock != RFB_INVALID_SOCKET)
     rfbCloseSocket(client->sock);
   if (client->listenSock != RFB_INVALID_SOCKET)
     rfbCloseSocket(client->listenSock);
   free(client->desktopName);

Fixed code:   free(client->vncRec);
CVE-2016-7145: Improper Authentication (CWE-287)
value: The m_authenticate function in ircd/m_authenticate.c in nefarious2 allows remote attackers to spoof certificate fingerprints and consequently log in as another user via a crafted AUTHENTICATE parameter.
CWE description: When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
CVSS v3 base score: 9.8
Published: 2017-03-07T15:59Z
Repository: https://github.com/evilnet/nefarious2
Language: C
Files changed: ircd/m_authenticate.c
Commit date: 2016-09-03 23:34:04 +0100
Commit message: Fix to prevent SASL security vulnerability

Diff: diff --git a/ircd/m_authenticate.c b/ircd/m_authenticate.c
index 99ed9ef..f8960bd 100644
--- a/ircd/m_authenticate.c
+++ b/ircd/m_authenticate.c
@@ -148,10 +148,12 @@ int m_authenticate(struct Client* cptr, struct Client* sptr, int parc, char* par
   else
     ircd_strncpy(realhost, hoststr, sizeof(realhost));
 
   if (acptr) {
     if (first) {
+      if (*parv[1] == ':' || strchr(parv[1], ' '))
+		return exit_client(cptr, sptr, sptr, "Malformed AUTHENTICATE");
       if (!EmptyString(cli_sslclifp(cptr)))
         sendcmdto_one(&me, CMD_SASL, acptr, "%C %C!%u.%u S %s :%s", acptr, &me,
                       cli_fd(cptr), cli_saslcookie(cptr),
                       parv[1], cli_sslclifp(cptr));
       else
@@ -165,10 +167,12 @@ int m_authenticate(struct Client* cptr, struct Client* sptr, int parc, char* par
       sendcmdto_one(&me, CMD_SASL, acptr, "%C %C!%u.%u C :%s", acptr, &me,
                     cli_fd(cptr), cli_saslcookie(cptr), parv[1]);
     }
   } else {
     if (first) {
+      if (*parv[1] == ':' || strchr(parv[1], ' '))
+        return exit_client(cptr, sptr, sptr, "Malformed AUTHENTICATE");
       if (!EmptyString(cli_sslclifp(cptr)))
         sendcmdto_serv_butone(&me, CMD_SASL, cptr, "* %C!%u.%u S %s :%s", &me,
                               cli_fd(cptr), cli_saslcookie(cptr),
                               parv[1], cli_sslclifp(cptr));
       else

Fixed code:       if (*parv[1] == ':' || strchr(parv[1], ' '))
		return exit_client(cptr, sptr, sptr, "Malformed AUTHENTICATE");
      if (*parv[1] == ':' || strchr(parv[1], ' '))
        return exit_client(cptr, sptr, sptr, "Malformed AUTHENTICATE");
CVE-2020-15093: Improper Verification of Cryptographic Signature (CWE-347)
value: The tough library (Rust/crates.io) prior to version 0.7.1 does not properly verify the threshold of cryptographic signatures. It allows an attacker to duplicate a valid signature in order to circumvent TUF requiring a minimum threshold of unique signatures before the metadata is considered valid. A fix is available in version 0.7.1. CVE-2020-6174 is assigned to the same vulnerability in the TUF reference implementation.
CWE description: The product does not verify, or incorrectly verifies, the cryptographic signature for data.
CVSS v3 base score: 8.6
Published: 2020-07-09T19:15Z
Repository: https://github.com/theupdateframework/tuf
Language: Unknown
Commit date: 2020-01-10 15:19:16 -0500
Commit message: Merge pull request #974 from lukpueh/fix-signature-threshold

Fix signature threshold
CVE-2020-15163: Insufficient Verification of Data Authenticity (CWE-345)
value: Python TUF (The Update Framework) reference implementation before version 0.12 it will incorrectly trust a previously downloaded root metadata file which failed verification at download time. This allows an attacker who is able to serve multiple new versions of root metadata (i.e. by a person-in-the-middle attack) culminating in a version which has not been correctly signed to control the trust chain for future updates. This is fixed in version 0.12 and newer.
CWE description: The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
CVSS v3 base score: 8.2
Published: 2020-09-09T18:15Z
Repository: https://github.com/theupdateframework/tuf
Language: Unknown
Commit date: 2019-10-07 11:54:59 +0200
Commit message: Merge pull request #885 from trishankatdatadog:trishankatdatadog/correctly-rotate-root

Signed-off-by: Lukas Puehringer <lukas.puehringer@nyu.edu>
CVE-2022-46179: Authorization Bypass Through User-Controlled Key (CWE-639)
value: LiuOS is a small Python project meant to imitate the functions of a regular operating system. Version 0.1.0 and prior of LiuOS allow an attacker to set the GITHUB_ACTIONS environment variable to anything other than null or true and skip authentication checks. This issue is patched in the latest commit (c658b4f3e57258acf5f6207a90c2f2169698ae22) by requiring the var to be set to true, causing a test script to run instead of being able to login. A potential workaround is to check for the GITHUB_ACTIONS environment variable and set it to "" (no quotes) to null the variable and force credential checks.
CWE description: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
CVSS v3 base score: 7.8
Published: 2022-12-28T08:15Z
Repository: https://github.com/LiuWoodsCode/LiuOS
Language: Python
Files changed: core.py
Commit date: 2022-12-27 14:04:46 -0500
Commit message: Fix authentication bypass exploit

Fixes the exploit by setting the requirement of the var to true, causing a side effect of the tests running, not the shell, making the exploit useless.
Diff: diff --git a/core.py b/core.py
index 5b368fa..f8d39f8 100644
--- a/core.py
+++ b/core.py
@@ -110,11 +110,11 @@ else:
         pwdreshash = bytehash.hexdigest()
         logging.debug('Generated hash of password')
         if attemps == 6:
         ## Brute force protection
            raise Exception("Too many password attempts. Because of the risk of a brute force attack, after 6 attempts, you will need to rerun LiuOS to try 6 more times.")
-        if os.environ.get('GITHUB_ACTIONS') != "":
+        if os.environ.get('GITHUB_ACTIONS') == "true":
             logging.warning("Running on Github Actions")
             actualsys()
         elif username == cred.loginname and pwdreshash == cred.loginpass:
             print(lang.SUCCESSFUL_LOGIN)
             logging.debug('Correct login credentials, logged in')

Vulnerable code:         if os.environ.get('GITHUB_ACTIONS') != "":
Fixed code:         if os.environ.get('GITHUB_ACTIONS') == "true":
CVE-2021-25976: Cross-Site Request Forgery (CSRF) (CWE-352)
value: In PiranhaCMS, versions 4.0.0-alpha1 to 9.2.0 are vulnerable to cross-site request forgery (CSRF) when performing various actions supported by the management system, such as deleting a user, deleting a role, editing a post, deleting a media folder etc., when an ID is known.
CWE description: The web application does not, or can not, sufficiently verify whether a well-formed, valid, consistent request was intentionally provided by the user who submitted the request.
CVSS v3 base score: 8.1
Published: 2021-11-16T09:15Z
Repository: https://github.com/PiranhaCMS/piranha.core
Language: Unknown
Commit date: 2021-10-25 21:47:54 +0200
Commit message: Merge pull request #1742 from PiranhaCMS/features/manager-security-update

Updated manager security. Fixes #1741