hitoshura25/cvefixes huggingface dataset:
CVE-2021-43523 (C, published 2021-11-10T15:15Z)
Description: value: In uClibc and uClibc-ng before 1.0.39, incorrect handling of special characters in domain names returned by DNS servers via gethostbyname, getaddrinfo, gethostbyaddr, and getnameinfo can lead to output of wrong hostnames (leading to domain hijacking) or injection into applications (leading to remote code execution, XSS, applications crashes, etc.). In other words, a validation step, which is expected in any stub resolver, does not occur.
Severity: MEDIUM (CVSS v3 base score: 9.6)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/wbx-github/uclibc-ng
Files changed:
libc/inet/resolv.c
Commit message: libc/inet/resolv.c: add __hnbad to check DNS entries for validity…

… using the same rules glibc does

also call __hnbad in some places to check answers


Vulnerable code:
				if (j && h.tc)
		if (i < 0) {

Fixed code:
extern int __hnbad(const char *dotted) attribute_hidden;
	int num_answers;
		/*XXX TODO: check that question matches query (and qdcount==1?) */
		num_answers = 0;
				if (num_answers && h.tc)
			if (__hnbad(ma.dotted))
				break;
			++num_answers;
		if (!num_answers) {
			h_errno = NO_RECOVERY;
			goto fail1;
		}
		if (i < 0 || __hnbad(buf)) {
		if (__hnbad(buf)) {
			*h_errnop = NO_RECOVERY;
			return -1;
		}
/*
 * __hnbad(dotted)
 *	Check whether a name is valid enough for DNS. The rules, as
 *	laid down by glibc, are:
 *	- printable input string
 *	- converts to label notation
 *	- each label only contains [0-9a-zA-Z_-], up to 63 octets
 *	- first label doesn’t begin with ‘-’
 *	This both is weaker than Unix hostnames (e.g. it allows
 *	underscores and leading/trailing hyphen-minus) and stronger
 *	than general (e.g. a leading “*.” is valid sometimes), take care.
 * return:
 *	0 if the name is ok
 */
int __hnbad(const char *dotted)
{
	unsigned char c, n, *cp;
	unsigned char buf[NS_MAXCDNAME];

	cp = (unsigned char *)dotted;
	while ((c = *cp++))
		if (c < 0x21 || c > 0x7E)
			return (1);
	if (ns_name_pton(dotted, buf, sizeof(buf)) < 0)
		return (2);
	if (buf[0] > 0 && buf[1] == '-')
		return (3);
	cp = buf;
	while ((n = *cp++)) {
		if (n > 63)
			return (4);
		while (n--) {
			c = *cp++;
			if (c < '-' ||
			    (c > '-' && c < '0') ||
			    (c > '9' && c < 'A') ||
			    (c > 'Z' && c < '_') ||
			    (c > '_' && c < 'a') ||
			    c > 'z')
				return (5);
		}
	}
	return (0);
}
CVE-2023-28428 (C, published 2023-03-20T15:15Z)
Description: value: PDFio is a C library for reading and writing PDF files. In versions 1.1.0 and prior, a denial of service vulnerability exists in the pdfio parser. Crafted pdf files can cause the program to run at 100% utilization and never terminate. This is different from CVE-2023-24808. A patch for this issue is available in version 1.1.1.
Severity: nan (CVSS v3 base score: 3.3)
Weakness: CWE-770 \u2014 Allocation of Resources Without Limits or Throttling
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.
Repository: https://github.com/michaelrsweet/pdfio
Files changed:
CHANGES.md
pdfio-stream.c
Commit message: Fix potential denial-of-service in flate stream code.


Vulnerable code:
v1.1.1 (Month DD, YYYY)
	else if (status == Z_STREAM_END)
	else if (status == Z_STREAM_END)

Fixed code:
v1.1.1 (March 20, 2023)
- CVE-2023-NNNNN: Fixed a potential denial-of-service with corrupt PDF files.
  uInt		avail_in, avail_out;	// Previous flate values
      avail_in  = st->flate.avail_in;
      avail_out = st->flate.avail_out;

      else if (avail_in == st->flate.avail_in && avail_out == st->flate.avail_out)
      {
	_pdfioFileError(st->pdf, "Corrupt stream data.");
	return (-1);
      }
        avail_in  = st->flate.avail_in;
        avail_out = st->flate.avail_out;

	else if (status == Z_STREAM_END || (avail_in == st->flate.avail_in && avail_out == st->flate.avail_out))
        avail_in  = st->flate.avail_in;
        avail_out = st->flate.avail_out;

	else if (status == Z_STREAM_END || (avail_in == st->flate.avail_in && avail_out == st->flate.avail_out))
CVE-2020-11072 (TypeScript, published 2020-05-12T01:15Z)
Description: value: In SLP Validate (npm package slp-validate) before version 1.2.1, users could experience false-negative validation outcomes for MINT transaction operations. A poorly implemented SLP wallet could allow spending of the affected tokens which would result in the destruction of a user's minting baton. This has been fixed in slp-validate in version 1.2.1. Additonally, slpjs version 0.27.2 has a related fix under related CVE-2020-11071.
Severity: MEDIUM (CVSS v3 base score: 8.6)
Weakness: CWE-697 \u2014 Incorrect Comparison
The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses.
Repository: https://github.com/simpleledger/slp-validate
Files changed:
lib/validation.ts
Commit message: fix false negative case for MINT transactions

See the newly added unit test case for this issue.
Currently there are 151 unit tests.


Vulnerable code:
            if (validation.parents.length !== 1) {
                validation.invalidReason = "MINT transaction must have 1 valid baton parent.";
        for (let i = 0; i < parentTxids.length; i++) {
            const valid = await this.isValidSlpTxid({ txid: parentTxids[i] });
            validation.parents.filter(p => p.txid === parentTxids[i]).map(p => p.valid = valid);
            if (validation.details!.transactionType === SlpTransactionType.MINT && !valid) {

Fixed code:
            if (validation.parents.length < 1) {
                validation.invalidReason = "MINT transaction must have at least 1 candidate baton parent input.";
        for (const id of parentTxids) {
            const valid = await this.isValidSlpTxid({ txid: id });
            validation.parents.filter(p => p.txid === id).map(p => p.valid = valid);
        }

        // Check MINT for exactly 1 valid MINT baton
        if (validation.details!.transactionType === SlpTransactionType.MINT) {
            if (validation.parents.filter(p => p.valid && p.inputQty === null).length !== 1) {
CVE-2021-36755 (JavaScript, published 2021-07-16T00:15Z)
Description: value: Nightscout Web Monitor (aka cgm-remote-monitor) 14.2.2 allows XSS via a crafted X-Forwarded-For header.
Severity: MEDIUM (CVSS v3 base score: 6.1)
Weakness: CWE-79 \u2014 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
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.
Repository: https://github.com/nightscout/cgm-remote-monitor
Files changed:
lib/client/adminnotifiesclient.js
lib/server/bootevent.js
Commit message: prevent XSS via admin-notifies system

The admin-notifies system takes user input from the X-Forwarded-For by header,
and injects it into html rendered by the browser in the admin-notification
system.  This patch appropriately escapes all such content injected into the
notification drawers.  This patch should prevent XSS attacks designed to
exploit user credentials or other access.  Thanks to Deja Vu Security -
Accenture, and Damien Sudol for reporting.


Vulnerable code:
  function wrapmessage(title, message, count, ago, persistent) {
    let html = '<hr><p><b>' + title + '</b></p><p class="adminNotifyMessage">' + message + '</p>';
    if (additional) html += '<p class="adminNotifyMessageAdditionalInfo">' + additional + '</p>'
    return html;
        html += wrapmessage(translate(m.title), translate(m.message), m.count, ago, m.persistent);
        ,message: "Your Nightscout installation is readable by anyone who knows the web page URL. Please consider closing access to the site by following the instructions in the <a href=\"http://nightscout.github.io/nightscout/security/#how-to-turn-off-unauthorized-access\" target=\"_new\">Nightscout documentation</a>."

Fixed code:
  function wrapmessage(title, message, count, ago, persistent, seeAlso) {
    let html = $('<div><div><hr><p><b class="adminNotifyTitle"></b></p><p class="adminNotifyMessage"></p></div><p class="adminNotifyMessageAdditionalInfo"></p></div>');
    html.find('.adminNotifyTitle').text(title);
    html.find('.adminNotifyMessage').text(message);
    html.find('.adminNotifyMessageAdditionalInfo').text(additional);
    if (seeAlso && init.addendums[seeAlso]) {
      html.append($(init.addendums[seeAlso]));
    }
    return html.html( );
        html += wrapmessage(translate(m.title), translate(m.message), m.count, ago, m.persistent, m.seeAlso);
init.addendums = {
  disableWorldReadable: '<p>Please consider closing access to the site by following the instructions in the <a href="http://nightscout.github.io/nightscout/security/#how-to-turn-off-unauthorized-access" target="_new">Nightscout documentation</a>.</p>'

};
        ,message: "Your Nightscout installation is readable by anyone who knows the web page URL."
        ,seeAlso: 'disableWorldReadable'
CVE-2024-32964 (JSON, published 2024-05-14T15:37Z)
Description: value: Lobe Chat is a chatbot framework that supports speech synthesis, multimodal, and extensible Function Call plugin system. Prior to 0.150.6, lobe-chat had an unauthorized Server-Side Request Forgery vulnerability in the /api/proxy endpoint. An attacker can construct malicious requests to cause Server-Side Request Forgery without logging in, attack intranet services, and leak sensitive information.
Severity: nan (CVSS v3 base score: )
Weakness: NVD-CWE-noinfo \u2014 Insufficient Information
There is insufficient information about the issue to classify it; details are unkown or unspecified.
Repository: https://github.com/lobehub/lobe-chat
Files changed:
package.json
src/app/api/proxy/route.ts
Commit message: 🐛 fix: fix `/api/proxy` internal proxy attack (#2255)



Vulnerable code:
export const runtime = 'edge';
  const url = await req.text();
  const res = await fetch(url);

Fixed code:
    "ip": "^2.0.1",
    "@types/ip": "^1.1.3",
import { isPrivate } from 'ip';
import { NextResponse } from 'next/server';
import dns from 'node:dns';
import { promisify } from 'node:util';

const lookupAsync = promisify(dns.lookup);

export const runtime = 'nodejs';
  const url = new URL(await req.text());
  let address;

  try {
    const lookupResult = await lookupAsync(url.hostname);
    address = lookupResult.address;
  } catch (err) {
    console.error(`${url.hostname} DNS parser error:`, err);

    return NextResponse.json({ error: 'DNS parser error' }, { status: 504 });
  }

  const isInternalHost = isPrivate(address);

  if (isInternalHost)
    return NextResponse.json({ error: 'Not support internal host proxy' }, { status: 400 });
  const res = await fetch(url.toString());
CVE-2024-1625 (TypeScript, published 2024-04-10T17:15Z)
Description: value: An Insecure Direct Object Reference (IDOR) vulnerability exists in the lunary-ai/lunary application version 0.3.0, allowing unauthorized deletion of any organization's project. The vulnerability is due to insufficient authorization checks in the project deletion endpoint, where the endpoint fails to verify if the project ID provided in the request belongs to the requesting user's organization. As a result, an attacker can delete projects belonging to any organization by sending a crafted DELETE request with the target project's ID. This issue affects the project deletion functionality implemented in the projects.delete route.
Severity: nan (CVSS v3 base score: )
Weakness: CWE-863 \u2014 Incorrect Authorization
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions.
Repository: https://github.com/lunary-ai/lunary
Files changed:
packages/backend/src/api/v1/projects/index.ts
packages/backend/src/utils/authorization.ts
Commit message: fix: project deletion safeguard


Vulnerable code:
  const { orgId } = ctx.state

Fixed code:
import { verifyProjectAccess } from "@/src/utils/authorization"
  const { orgId, userId } = ctx.state
  console.log(ctx.state)

  const hasProjectAccess = await verifyProjectAccess(projectId, userId)
  const [user] = await sql`select * from account where id = ${userId}`

  if (!hasProjectAccess) {
    ctx.throw(401, "Not allowed")
  }

  if (user.role !== "admin") {
    ctx.throw(403, "You must be an admin to delete a project")
  }
    ctx.body = {}
import sql from "./db"

export async function verifyProjectAccess(projectId: string, userId: string) {
  const [{ exists: hasAccess }] = await sql`
      select exists (
        select 1 
        from project 
        where org_id = (select org_id from account where id = ${userId}) 
          and id = ${projectId}
      )
    `
  return hasAccess
}
CVE-2024-1626 (TypeScript, published 2024-04-16T00:15Z)
Description: value: An Insecure Direct Object Reference (IDOR) vulnerability exists in the lunary-ai/lunary repository, version 0.3.0, within the project update endpoint. The vulnerability allows authenticated users to modify the name of any project within the system without proper authorization checks, by directly referencing the project's ID in the PATCH request to the '/v1/projects/:projectId' endpoint. This issue arises because the endpoint does not verify if the provided project ID belongs to the currently authenticated user, enabling unauthorized modifications across different organizational projects.
Severity: nan (CVSS v3 base score: )
Weakness: CWE-250 \u2014 Execution with Unnecessary Privileges
The product performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
Repository: https://github.com/lunary-ai/lunary
Files changed:
packages/backend/src/api/v1/projects/index.ts
packages/backend/src/utils/authorization.ts
Commit message: feat: add project modification safeguard


Vulnerable code:
import { verifyProjectAccess } from "@/src/utils/authorization"
  console.log(ctx.state)
  const hasProjectAccess = await verifyProjectAccess(projectId, userId)
export async function verifyProjectAccess(projectId: string, userId: string) {

Fixed code:
import { checkProjectAccess } from "@/src/utils/authorization"
  const hasProjectAccess = await checkProjectAccess(projectId, userId)
  const { userId } = ctx.params

  const hasProjectAccess = await checkProjectAccess(projectId, userId)
  if (!hasProjectAccess) {
    ctx.throw(401, "Unauthorized")
  }

export async function checkProjectAccess(projectId: string, userId: string) {
CVE-2024-1666 (TypeScript, published 2024-04-16T00:15Z)
Description: value: In lunary-ai/lunary version 1.0.0, an authorization flaw exists that allows unauthorized radar creation. The vulnerability stems from the lack of server-side checks to verify if a user is on a free account during the radar creation process, which is only enforced in the web UI. As a result, attackers can bypass the intended account upgrade requirement by directly sending crafted requests to the server, enabling the creation of an unlimited number of radars without payment.
Severity: nan (CVSS v3 base score: )
Weakness: CWE-770 \u2014 Allocation of Resources Without Limits or Throttling
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.
Repository: https://github.com/lunary-ai/lunary
Files changed:
packages/backend/src/api/v1/evaluations/index.ts
packages/backend/src/api/v1/projects/index.ts
packages/backend/src/api/v1/radars.ts
Commit message: fix: security patches (#192)



Vulnerable code:
import Router from "koa-router"
import { getReadableDateTime } from "@/src/utils/date"
import { runEval } from "./utils"
import { getEvaluation } from "./utils"
import { calcRunCost } from "@/src/utils/calcCost"
import { runChecksOnRun } from "@/src/checks/runChecks"
import { checkAccess } from "@/src/utils/authorization"
import { RunEvent } from "lunary/types"
    const { userId, projectId } = ctx.state
    // Define the schema for request body validation using Zod
  const { projectId, userId } = ctx.state

Fixed code:
import { runChecksOnRun } from "@/src/checks/runChecks"
import { checkAccess } from "@/src/utils/authorization"
import { calcRunCost } from "@/src/utils/calcCost"
import { getReadableDateTime } from "@/src/utils/date"
import Router from "koa-router"
import { RunEvent } from "lunary/types"
import { runEval } from "./utils"
    const { userId, projectId, orgId } = ctx.state
    const [{ plan }] =
      await sql`select plan, eval_allowance from org where id = ${orgId}`
    if (plan === "free") {
      ctx.throw(403, "You can't create evaluations on the free plan.")
    }

    const [hasAccess] =
      await sql`select * from account_project where project_id = ${projectId} and account_id = ${userId}`
    if (!hasAccess) {
      ctx.throw(401, "Not allowed")
    }

  const { projectId, userId, orgId } = ctx.state
  const [{ plan }] =
    await sql`select plan, eval_allowance from org where id = ${orgId}`
  if (plan === "free") {
    ctx.throw(403, "You can't create evaluations on the free plan.")
  }
CVE-2024-1738 (JSON, published 2024-04-16T00:15Z)
Description: value: An incorrect authorization vulnerability exists in the lunary-ai/lunary repository, specifically within the evaluations.get route in the evaluations API endpoint. This vulnerability allows unauthorized users to retrieve the results of any organization's evaluation by simply knowing the evaluation ID, due to the lack of project ID verification in the SQL query. As a result, attackers can gain access to potentially private data contained within the evaluation results.
Severity: nan (CVSS v3 base score: )
Weakness: CWE-863 \u2014 Incorrect Authorization
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions.
Repository: https://github.com/lunary-ai/lunary
Files changed:
package.json
packages/backend/src/api/v1/evaluations/index.ts
Commit message: fix: get evaluation result (#181)



Vulnerable code:
    "dev": "concurrently \"npm run dev:frontend\" \"npm run dev:backend\" \"npm run dev:radar\"",
  select 
    *,
    p.id as prompt_id
  from 
    evaluation_result er 
    left join dataset_prompt p on p.id = er.prompt_id
    left join dataset_prompt_variation pv on pv.id = er.variation_id
  where 
    er.evaluation_id = ${evaluationId}`

Fixed code:
    "dev": "concurrently \"npm run dev:frontend\" \"npm run dev:backend\"",
    const { projectId } = ctx.state
      select 
        *,
        p.id as prompt_id
      from 
        evaluation_result er 
        left join evaluation e on e.id = er.evaluation_id
        left join dataset_prompt p on p.id = er.prompt_id
        left join dataset_prompt_variation pv on pv.id = er.variation_id
      where 
        er.evaluation_id = ${evaluationId}
        and e.project_id = ${projectId}
      `
CVE-2024-1739 (TypeScript, published 2024-04-16T00:15Z)
Description: value: lunary-ai/lunary is vulnerable to an authentication issue due to improper validation of email addresses during the signup process. Specifically, the server fails to treat email addresses as case insensitive, allowing the creation of multiple accounts with the same email address by varying the case of the email characters. For example, accounts for 'abc@gmail.com' and 'Abc@gmail.com' can both be created, leading to potential impersonation and confusion among users.
Severity: nan (CVSS v3 base score: )
Weakness: CWE-821 \u2014 Incorrect Synchronization
The product utilizes a shared resource in a concurrent manner, but it does not correctly synchronize access to the resource.
Repository: https://github.com/lunary-ai/lunary
Files changed:
packages/backend/src/api/v1/auth/index.ts
Commit message: fix: case sensitivity for existing user verification


Vulnerable code:
    select * from account where email = ${email}

Fixed code:
    select * from account where lower(email) = lower(${email})
CVE-2024-1740 (TypeScript, published 2024-04-10T17:15Z)
Description: value: In lunary-ai/lunary version 1.0.1, a vulnerability exists where a user removed from an organization can still read, create, modify, and delete logs by re-using an old authorization token. The lunary web application communicates with the server using an 'Authorization' token in the browser, which does not properly invalidate upon the user's removal from the organization. This allows the removed user to perform unauthorized actions on logs and access project and external user details without valid permissions.
Severity: nan (CVSS v3 base score: )
Weakness: CWE-863 \u2014 Incorrect Authorization
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. This allows attackers to bypass intended access restrictions.
Repository: https://github.com/lunary-ai/lunary
Files changed:
packages/backend/src/api/v1/evaluations/index.ts
packages/backend/src/api/v1/projects/index.ts
packages/backend/src/api/v1/radars.ts
Commit message: fix: security patches (#192)



Vulnerable code:
import Router from "koa-router"
import { getReadableDateTime } from "@/src/utils/date"
import { runEval } from "./utils"
import { getEvaluation } from "./utils"
import { calcRunCost } from "@/src/utils/calcCost"
import { runChecksOnRun } from "@/src/checks/runChecks"
import { checkAccess } from "@/src/utils/authorization"
import { RunEvent } from "lunary/types"
    const { userId, projectId } = ctx.state
    // Define the schema for request body validation using Zod
  const { projectId, userId } = ctx.state

Fixed code:
import { runChecksOnRun } from "@/src/checks/runChecks"
import { checkAccess } from "@/src/utils/authorization"
import { calcRunCost } from "@/src/utils/calcCost"
import { getReadableDateTime } from "@/src/utils/date"
import Router from "koa-router"
import { RunEvent } from "lunary/types"
import { runEval } from "./utils"
    const { userId, projectId, orgId } = ctx.state
    const [{ plan }] =
      await sql`select plan, eval_allowance from org where id = ${orgId}`
    if (plan === "free") {
      ctx.throw(403, "You can't create evaluations on the free plan.")
    }

    const [hasAccess] =
      await sql`select * from account_project where project_id = ${projectId} and account_id = ${userId}`
    if (!hasAccess) {
      ctx.throw(401, "Not allowed")
    }

  const { projectId, userId, orgId } = ctx.state
  const [{ plan }] =
    await sql`select plan, eval_allowance from org where id = ${orgId}`
  if (plan === "free") {
    ctx.throw(403, "You can't create evaluations on the free plan.")
  }