starsofchance/CVEfixes_v1.0.8 huggingface dataset:
CVE-2023-46929 (published 2024-01-03T19:15Z)

An issue discovered in GPAC 2.3-DEV-rev605-gfc9e29089-master in MP4Box in gf_avc_change_vui /afltest/gpac/src/media_tools/av_parsers.c:6872:55 allows attackers to crash the application.

CVSS v3 base score: 7.5, HIGH (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

Weakness information:
cwe_id: NVD-CWE-noinfo
cwe_name: Insufficient Information
description: There is insufficient information about the issue to classify it; details are unkown or unspecified.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/gpac/gpac
commit_details: repo_url: https://github.com/gpac/gpac
author: Aurelien David
author_date: 2023-10-26 11:29:52+02:00
msg: add nullguard on gf_avc_change_vui (fixes #2662)
repository: repo_url: https://github.com/gpac/gpac
repo_name: gpac/gpac
description: GPAC Ultramedia OSS for Video Streaming & Next-Gen Multimedia Transcoding, Packaging & Delivery
repo_language: C
owner: gpac
file_changes: filename: av_parsers.c
change_type: ModificationType.MODIFY
diff: @@ -6865,6 +6865,9 @@ GF_Err gf_avc_change_vui(GF_AVCConfig *avcc, GF_VUIInfo *vui_info)
 	GF_AVCConfigSlot *slc;
 	orig = NULL;
 
+	if (!avcc)
+		return GF_NON_COMPLIANT_BITSTREAM;
+
 	memset(&avc, 0, sizeof(AVCState));
 	avc.sps_active_idx = -1;
 

programming_language: C
CVE-2012-6084 (published 2013-01-01T15:55Z)

modules/m_capab.c in (1) ircd-ratbox before 3.0.8 and (2) Charybdis before 3.4.2 does not properly support capability negotiation during server handshakes, which allows remote attackers to cause a denial of service (NULL pointer dereference and daemon crash) via a malformed request.

Severity: MEDIUM
CVSS v2 base score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)

Weakness information:
cwe_id: NVD-CWE-Other
cwe_name: Other
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.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/atheme/charybdis
commit_details: repo_url: https://github.com/atheme/charybdis
author: William Pitcock
author_date: 2012-12-31 13:13:05-06:00
msg: m_capab: fix a possible remote crash triggered by the CAPAB parsing code.
repository: repo_url: https://github.com/atheme/charybdis
repo_name: charybdis-ircd/charybdis
description: Scalable IRCv3.2 server for large, community-oriented networks
repo_language: C
owner: atheme
file_changes: filename: m_capab.c
change_type: ModificationType.MODIFY
diff: @@ -38,7 +38,7 @@ static int me_gcap(struct Client *, struct Client *, int, const char **);
 
 struct Message capab_msgtab = {
 	"CAPAB", 0, 0, 0, MFLG_SLOW | MFLG_UNREG,
-	{{mr_capab, 0}, mg_ignore, mg_ignore, mg_ignore, mg_ignore, mg_ignore}
+	{{mr_capab, 2}, mg_ignore, mg_ignore, mg_ignore, mg_ignore, mg_ignore}
 };
 struct Message gcap_msgtab = {
 	"GCAP", 0, 0, 0, MFLG_SLOW,

programming_language: C
CVE-2023-23607 (published 2023-01-20T21:15Z)

erohtar/Dasherr is a dashboard for self-hosted services. In affected versions unrestricted file upload allows any unauthenticated user to execute arbitrary code on the server. The file /www/include/filesave.php allows for any file to uploaded to anywhere. If an attacker uploads a php file they can execute code on the server. This issue has been addressed in version 1.05.00. Users are advised to upgrade. There are no known workarounds for this issue.\n

CVSS v3 base score: 9.8, CRITICAL (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-434
cwe_name: Unrestricted Upload of File with Dangerous Type
description: The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.
extended_description: 
            
            
            
            
            
         
         

Fix information:
repo_url: https://github.com/erohtar/Dasherr
commit_details: repo_url: https://github.com/erohtar/Dasherr
author: erohtar
author_date: 2023-01-20 01:25:00+05:30
msg: Update filesave.php
repository: repo_url: https://github.com/erohtar/Dasherr
repo_name: erohtar/Dasherr
description: A minimal and lightweight dashboard for your self-hosted services (and bookmarks)
repo_language: JavaScript
owner: erohtar
file_changes: filename: filesave.php
change_type: ModificationType.MODIFY
diff: @@ -3,7 +3,7 @@ if(!empty($_POST['data'])){
 	$fname = $_POST['file'];
 
 	//check if file name ends with .json
-	if(substr($fname, -1, 5) != '.json') {
+	if(substr($fname, -5) != '.json') {
 		echo '<script>alert("ERROR: Incorrect file type submitted")</script>';
 		return;
 	}

programming_language: PHP
CVE-2017-14170 (published 2017-09-07T06:29Z)

In libavformat/mxfdec.c in FFmpeg 3.3.3 -> 2.4, a DoS in mxf_read_index_entry_array() due to lack of an EOF (End of File) check might cause huge CPU consumption. When a crafted MXF file, which claims a large "nb_index_entries" field in the header but does not contain sufficient backing data, is provided, the loop would consume huge CPU resources, since there is no EOF check inside the loop. Moreover, this big loop can be invoked multiple times if there is more than one applicable data segment in the crafted MXF file.

Severity: HIGH
CVSS v2 base score: 7.1 (AV:N/AC:M/Au:N/C:N/I:N/A:C)
CVSS v3 base score: 6.5, MEDIUM (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H)

Weakness information:
cwe_id: CWE-834
cwe_name: Excessive Iteration
description: The product performs an iteration or loop without sufficiently limiting the number of times that the loop is executed.
extended_description: If the iteration can be influenced by an attacker, this weakness could allow attackers to consume excessive resources such as CPU or memory. In many cases, a loop does not need to be infinite in order to cause enough resource consumption to adversely affect the product or its host system; it depends on the amount of resources consumed per iteration.
         

Fix information:
repo_url: https://github.com/FFmpeg/FFmpeg
commit_details: repo_url: https://github.com/FFmpeg/FFmpeg
author: 孙浩(晓黑)
author_date: 2017-08-29 23:59:21+02:00
msg: avformat/mxfdec: Fix DoS issues in mxf_read_index_entry_array()

Fixes: 20170829A.mxf

Co-Author: 张洪亮(望初)" <wangchu.zhl@alibaba-inc.com>
Found-by: Xiaohei and Wangchu from Alibaba Security Team
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
repository: repo_url: https://github.com/FFmpeg/FFmpeg
repo_name: FFmpeg/FFmpeg
description: Mirror of https://git.ffmpeg.org/ffmpeg.git
repo_language: C
owner: FFmpeg
file_changes: filename: mxfdec.c
change_type: ModificationType.MODIFY
diff: @@ -899,6 +899,8 @@ static int mxf_read_index_entry_array(AVIOContext *pb, MXFIndexTableSegment *seg
     segment->nb_index_entries = avio_rb32(pb);
 
     length = avio_rb32(pb);
+    if(segment->nb_index_entries && length < 11)
+        return AVERROR_INVALIDDATA;
 
     if (!(segment->temporal_offset_entries=av_calloc(segment->nb_index_entries, sizeof(*segment->temporal_offset_entries))) ||
         !(segment->flag_entries          = av_calloc(segment->nb_index_entries, sizeof(*segment->flag_entries))) ||
@@ -909,6 +911,8 @@ static int mxf_read_index_entry_array(AVIOContext *pb, MXFIndexTableSegment *seg
     }
 
     for (i = 0; i < segment->nb_index_entries; i++) {
+        if(avio_feof(pb))
+            return AVERROR_INVALIDDATA;
         segment->temporal_offset_entries[i] = avio_r8(pb);
         avio_r8(pb);                                        /* KeyFrameOffset */
         segment->flag_entries[i] = avio_r8(pb);

programming_language: C
CVE-2012-2127 (published 2012-06-21T23:55Z)

fs/proc/root.c in the procfs implementation in the Linux kernel before 3.2 does not properly interact with CLONE_NEWPID clone system calls, which allows remote attackers to cause a denial of service (reference leak and memory consumption) by making many connections to a daemon that uses PID namespaces to isolate clients, as demonstrated by vsftpd.

Severity: MEDIUM
CVSS v2 base score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)

Weakness information:
cwe_id: CWE-119
cwe_name: Improper Restriction of Operations within the Bounds of a Memory Buffer
description: The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
extended_description: 
            Certain languages allow direct addressing of memory locations and do not automatically ensure that these locations are valid for the memory buffer that is being referenced. This can cause read or write operations to be performed on memory locations that may be associated with other variables, data structures, or internal program data.
         
         

Fix information:
repo_url: https://github.com/torvalds/linux
commit_details: repo_url: https://github.com/torvalds/linux
author: Al Viro
author_date: 2011-12-08 23:20:45-05:00
msg: procfs: fix a vfsmount longterm reference leak

kern_mount() doesn't pair with plain mntput()...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
repository: repo_url: https://github.com/torvalds/linux
repo_name: torvalds/linux
description: Linux kernel source tree
repo_language: C
owner: torvalds
file_changes: filename: root.c
change_type: ModificationType.MODIFY
diff: @@ -91,20 +91,18 @@ static struct file_system_type proc_fs_type = {
 
 void __init proc_root_init(void)
 {
-	struct vfsmount *mnt;
 	int err;
 
 	proc_init_inodecache();
 	err = register_filesystem(&proc_fs_type);
 	if (err)
 		return;
-	mnt = kern_mount_data(&proc_fs_type, &init_pid_ns);
-	if (IS_ERR(mnt)) {
+	err = pid_ns_prepare_proc(&init_pid_ns);
+	if (err) {
 		unregister_filesystem(&proc_fs_type);
 		return;
 	}
 
-	init_pid_ns.proc_mnt = mnt;
 	proc_symlink("mounts", NULL, "self/mounts");
 
 	proc_net_init();
@@ -209,5 +207,5 @@ int pid_ns_prepare_proc(struct pid_namespace *ns)
 
 void pid_ns_release_proc(struct pid_namespace *ns)
 {
-	mntput(ns->proc_mnt);
+	kern_unmount(ns->proc_mnt);
 }

programming_language: C
CVE-2024-2314 (published 2024-03-10T23:15Z)

If kernel headers need to be extracted, bcc will attempt to load them from a temporary directory. An unprivileged attacker could use this to force bcc to load compromised linux headers. Linux distributions which provide kernel headers by default are not affected by default.


Weakness information:
cwe_id: NVD-CWE-noinfo
cwe_name: Insufficient Information
description: There is insufficient information about the issue to classify it; details are unkown or unspecified.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/iovisor/bcc
commit_details: repo_url: https://github.com/iovisor/bcc
author: Brendan Gregg
author_date: 2024-03-07 05:27:14+11:00
msg: clang: check header ownership (#4928)

Example testing with a brendan-owned /tmp/kheaders file (note the "ERROR:" message):

~/bcc/build$ sudo /usr/share/bcc/tools/biosnoop
ERROR: header file ownership unexpected: /tmp/kheaders-5.15.47-internal
<built-in>:1:10: fatal error: './include/linux/kconfig.h' file not found
#include "./include/linux/kconfig.h"
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Traceback (most recent call last):
  File "/usr/share/bcc/tools/biosnoop", line 335, in <module>
    b = BPF(text=bpf_text)
  File "/usr/lib/python3/dist-packages/bcc-0.1.5+6cd27218-py3.10.egg/bcc/__init__.py", line 479, in __init__
Exception: Failed to compile BPF module <text>
~/bcc/build$ ls -lhd /tmp/kheaders-5.15.47-internal
drwxrwxr-x 2 brendan dev 4.0K Mar  6 02:50 /tmp/kheaders-5.15.47-internal

No error when chown'd back to root.
repository: repo_url: https://github.com/iovisor/bcc
repo_name: iovisor/bcc
description: BCC - Tools for BPF-based Linux IO analysis, networking, monitoring, and more
repo_language: C
owner: iovisor
file_changes: filename: kbuild_helper.cc
change_type: ModificationType.MODIFY
diff: @@ -140,15 +140,22 @@ int KBuildHelper::get_flags(const char *uname_machine, vector<string> *cflags) {
   return 0;
 }
 
-static inline int file_exists(const char *f)
+static inline int file_exists_and_ownedby(const char *f, uid_t uid)
 {
   struct stat buffer;
-  return (stat(f, &buffer) == 0);
+  int ret;
+  if ((ret = stat(f, &buffer)) == 0) {
+    if (buffer.st_uid != uid) {
+      std::cout << "ERROR: header file ownership unexpected: " << std::string(f) << "\n";
+      return -1;
+    }
+  }
+  return ret;
 }
 
 static inline int proc_kheaders_exists(void)
 {
-  return file_exists(PROC_KHEADERS_PATH);
+  return file_exists_and_ownedby(PROC_KHEADERS_PATH, 0);
 }
 
 static inline const char *get_tmp_dir() {
@@ -224,7 +231,7 @@ int get_proc_kheaders(std::string &dirpath)
            uname_data.release);
   dirpath = std::string(dirpath_tmp);
 
-  if (file_exists(dirpath_tmp))
+  if (file_exists_and_ownedby(dirpath_tmp, 0))
     return 0;
 
   // First time so extract it

programming_language: C++
CVE-2015-8953 (published 2016-10-16T21:59Z)

fs/overlayfs/copy_up.c in the Linux kernel before 4.2.6 uses an incorrect cleanup code path, which allows local users to cause a denial of service (dentry reference leak) via filesystem operations on a large file in a lower overlayfs layer.

Severity: MEDIUM
CVSS v2 base score: 4.9 (AV:L/AC:L/Au:N/C:N/I:N/A:C)
CVSS v3 base score: 5.5, MEDIUM (CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)

Weakness information:
cwe_id: CWE-399
cwe_name: Resource Management Errors
description: Weaknesses in this category are related to improper management of system resources.

Fix information:
repo_url: https://github.com/torvalds/linux
commit_details: repo_url: https://github.com/torvalds/linux
author: David Howells
author_date: 2015-09-18 11:45:22+01:00
msg: ovl: fix dentry reference leak

In ovl_copy_up_locked(), newdentry is leaked if the function exits through
out_cleanup as this just to out after calling ovl_cleanup() - which doesn't
actually release the ref on newdentry.

The out_cleanup segment should instead exit through out2 as certainly
newdentry leaks - and possibly upper does also, though this isn't caught
given the catch of newdentry.

Without this fix, something like the following is seen:

	BUG: Dentry ffff880023e9eb20{i=f861,n=#ffff880023e82d90} still in use (1) [unmount of tmpfs tmpfs]
	BUG: Dentry ffff880023ece640{i=0,n=bigfile}  still in use (1) [unmount of tmpfs tmpfs]

when unmounting the upper layer after an error occurred in copyup.

An error can be induced by creating a big file in a lower layer with
something like:

	dd if=/dev/zero of=/lower/a/bigfile bs=65536 count=1 seek=$((0xf000))

to create a large file (4.1G).  Overlay an upper layer that is too small
(on tmpfs might do) and then induce a copy up by opening it writably.

Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Miklos Szeredi <miklos@szeredi.hu>
Cc: <stable@vger.kernel.org> # v3.18+
repository: repo_url: https://github.com/torvalds/linux
repo_name: torvalds/linux
description: Linux kernel source tree
repo_language: C
owner: torvalds
file_changes: filename: copy_up.c
change_type: ModificationType.MODIFY
diff: @@ -267,7 +267,7 @@ static int ovl_copy_up_locked(struct dentry *workdir, struct dentry *upperdir,
 
 out_cleanup:
 	ovl_cleanup(wdir, newdentry);
-	goto out;
+	goto out2;
 }
 
 /*

programming_language: C
CVE-2022-39263 (published 2022-09-28T21:15Z)

`@next-auth/upstash-redis-adapter` is the Upstash Redis adapter for NextAuth.js, which provides authentication for Next.js. Applications that use `next-auth` Email Provider and `@next-auth/upstash-redis-adapter` before v3.0.2 are affected by this vulnerability. The Upstash Redis adapter implementation did not check for both the identifier (email) and the token, but only checking for the identifier when verifying the token in the email callback flow. An attacker who knows about the victim's email could easily sign in as the victim, given the attacker also knows about the verification token's expired duration. The vulnerability is patched in v3.0.2. A workaround is available. Using Advanced Initialization, developers can check the requests and compare the query's token and identifier before proceeding.

CVSS v3 base score: 8.1, HIGH (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-287
cwe_name: Improper Authentication
description: When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
extended_description: 
            
			
         
         

Fix information:
repo_url: https://github.com/nextauthjs/next-auth
commit_details: repo_url: https://github.com/nextauthjs/next-auth
author: voinik
author_date: 2022-09-25 10:10:55+02:00
msg: fix(adapters): check token during email verification in Upstash Adapter (#5377)

* Check token during email verification

* Undo accidental linter fix

* Update index.ts

Co-authored-by: Balázs Orbán <info@balazsorban.com>
repository: repo_url: https://github.com/nextauthjs/next-auth
repo_name: nextauthjs/next-auth
description: Authentication for the Web.
repo_language: TypeScript
owner: nextauthjs
file_changes: filename: index.ts
change_type: ModificationType.MODIFY
diff: @@ -165,13 +165,20 @@ export function UpstashRedisAdapter(
     },
     async createVerificationToken(verificationToken) {
       await setObjectAsJson(
-        verificationTokenKeyPrefix + verificationToken.identifier,
+        verificationTokenKeyPrefix +
+          verificationToken.identifier +
+          ":" +
+          verificationToken.token,
         verificationToken
       )
       return verificationToken
     },
     async useVerificationToken(verificationToken) {
-      const tokenKey = verificationTokenKeyPrefix + verificationToken.identifier
+      const tokenKey =
+        verificationTokenKeyPrefix +
+        verificationToken.identifier +
+        ":" +
+        verificationToken.token
 
       const token = await client.get<VerificationToken>(tokenKey)
       if (!token) return null

programming_language: TypeScript
CVE-2011-2905 (published 2013-03-01T12:37Z)

Untrusted search path vulnerability in the perf_config function in tools/perf/util/config.c in perf, as distributed in the Linux kernel before 3.1, allows local users to overwrite arbitrary files via a crafted config file in the current working directory.

Severity: MEDIUM
CVSS v2 base score: 6.2 (AV:L/AC:H/Au:N/C:C/I:C/A:C)

Weakness information:
cwe_id: NVD-CWE-Other
cwe_name: Other
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.
extended_description: Insufficient Information

Fix information:
repo_url: https://github.com/torvalds/linux
commit_details: repo_url: https://github.com/torvalds/linux
author: Jonathan Nieder
author_date: 2011-08-05 18:58:38+02:00
msg: perf tools: do not look at ./config for configuration

In addition to /etc/perfconfig and $HOME/.perfconfig, perf looks for
configuration in the file ./config, imitating git which looks at
$GIT_DIR/config.  If ./config is not a perf configuration file, it
fails, or worse, treats it as a configuration file and changes behavior
in some unexpected way.

"config" is not an unusual name for a file to be lying around and perf
does not have a private directory dedicated for its own use, so let's
just stop looking for configuration in the cwd.  Callers needing
context-sensitive configuration can use the PERF_CONFIG environment
variable.

Requested-by: Christian Ohm <chr.ohm@gmx.net>
Cc: 632923@bugs.debian.org
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Christian Ohm <chr.ohm@gmx.net>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20110805165838.GA7237@elie.gateway.2wire.net
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
repository: repo_url: https://github.com/torvalds/linux
repo_name: torvalds/linux
description: Linux kernel source tree
repo_language: C
owner: torvalds
file_changes: filename: config.c
change_type: ModificationType.MODIFY
diff: @@ -399,7 +399,6 @@ static int perf_config_global(void)
 int perf_config(config_fn_t fn, void *data)
 {
 	int ret = 0, found = 0;
-	char *repo_config = NULL;
 	const char *home = NULL;
 
 	/* Setting $PERF_CONFIG makes perf read _only_ the given config file. */
@@ -421,12 +420,6 @@ int perf_config(config_fn_t fn, void *data)
 		free(user_config);
 	}
 
-	repo_config = perf_pathdup("config");
-	if (!access(repo_config, R_OK)) {
-		ret += perf_config_from_file(fn, repo_config, data);
-		found += 1;
-	}
-	free(repo_config);
 	if (found == 0)
 		return -1;
 	return ret;

programming_language: C
CVE-2021-21363 (published 2021-03-11T03:15Z)

swagger-codegen is an open-source project which contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition. In swagger-codegen before version 2.4.19, on Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. This vulnerability is local privilege escalation because the contents of the `outputFolder` can be appended to by an attacker. As such, code written to this directory, when executed can be attacker controlled. For more details refer to the referenced GitHub Security Advisory. This vulnerability is fixed in version 2.4.19. Note this is a distinct vulnerability from CVE-2021-21364.

Severity: MEDIUM
CVSS v2 base score: 4.4 (AV:L/AC:M/Au:N/C:P/I:P/A:P)
CVSS v3 base score: 7.0, HIGH (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)

Weakness information:
cwe_id: CWE-378
cwe_name: Creation of Temporary File With Insecure Permissions
description: Opening temporary files without appropriate measures or controls can leave the file, its contents and any function that it impacts vulnerable to attack.
extended_description: 
            
         
         
cwe_id: CWE-379
cwe_name: Creation of Temporary File in Directory with Insecure Permissions
description: The product creates a temporary file in a directory whose permissions allow unintended actors to determine the file's existence or otherwise access that file.
extended_description: On some operating systems, the fact that the temporary file exists may be apparent to any user with sufficient privileges to access that directory. Since the file is visible, the application that is using the temporary file could be known. If one has access to list the processes on the system, the attacker has gained information about what the user is doing at that time. By correlating this with the applications the user is running, an attacker could potentially discover what a user's actions are. From this, higher levels of security could be breached.
         

Fix information:
repo_url: https://github.com/swagger-api/swagger-codegen
commit_details: repo_url: https://github.com/swagger-api/swagger-codegen
author: Francesco Tumanischvili
author_date: 2021-03-02 11:05:49+01:00
msg: Merge pull request from GHSA-pc22-3g76-gm6j

 security: use java.nio.files in Generator.
repository: repo_url: https://github.com/swagger-api/swagger-codegen
repo_name: swagger-api/swagger-codegen
description: swagger-codegen contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition.
repo_language: Mustache
owner: swagger-api