VYPR
High severityNVD Advisory· Published Mar 14, 2018· Updated Sep 17, 2024

CVE-2018-0936

CVE-2018-0936

Description

ChakraCore and Microsoft Windows 10 1709 are prone to a remote code execution vulnerability due to incorrect byte code generation for named function expressions.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

ChakraCore and Microsoft Windows 10 1709 are prone to a remote code execution vulnerability due to incorrect byte code generation for named function expressions.

Vulnerability

CVE-2018-0936 is a memory corruption vulnerability in the Chakra scripting engine (ChakraCore and Microsoft Edge on Windows 10 1709). The bug occurs in the JavaScript parser when generating byte code for captured function expressions. As shown in the fix at commit 64e7619 [2], the parser incorrectly handled SetNameIsHidden for named function expressions when a local declaration with the same name exists, leading to an object memory handling error [3][4]. All versions of ChakraCore prior to the commit and Microsoft Edge on affected Windows 10 builds are vulnerable.

Exploitation

An attacker can trigger the vulnerability by convincing a user to visit a specially crafted web page hosting malicious JavaScript [4]. No additional authentication or privileges are required; the attack is remote and relies on the user processing the content in Internet Explorer or Edge. The crafted JavaScript causes the Chakra engine to incorrectly process function expression names in memory, leading to corruption [1][3].

Impact

Successful exploitation allows remote code execution in the context of the current user. The memory corruption can be leveraged to execute arbitrary code, potentially leading to full compromise of the user's system [1][4].

Mitigation

Microsoft released a security update on March 13, 2018 as part of the monthly Patch Tuesday [3][4]. Users should install the update via Windows Update. ChakraCore users should update to builds after commit 64e7619 [2]. No workaround is available; the fix is included in the standard cumulative update.

AI Insight generated on May 22, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected packages

Versions sourced from the GitHub Security Advisory.

PackageAffected versionsPatched versions
Microsoft.ChakraCoreNuGet
< 1.8.21.8.2

Affected products

2
  • ghsa-coords
    Range: < 1.8.2
  • Microsoft Corporation/ChakraCore, Microsoft Edgev5
    Range: ChakraCore and Microsoft Windows 10 1709.

Patches

1
64e761923df0

[CVE-2018-0936] Incorrect byte code for captured function expression name may lead to OOB - Internal

https://github.com/chakra-core/ChakraCorePaul LeathersFeb 7, 2018via ghsa
5 files changed · +14 49
  • lib/Parser/Parse.cpp+0 24 modified
    @@ -932,21 +932,6 @@ Symbol* Parser::AddDeclForPid(ParseNodePtr pnode, IdentPtr pid, SymbolType symbo
                 CheckRedeclarationErrorForBlockId(pid, pnodeFnc->sxFnc.pnodeScopes->sxBlock.blockId);
             }
     
    -        if ((scope->GetScopeType() == ScopeType_FunctionBody || scope->GetScopeType() == ScopeType_Parameter) && symbolType != STFunction)
    -        {
    -            AnalysisAssert(pnodeFnc);
    -            if (pnodeFnc->sxFnc.pnodeName &&
    -                pnodeFnc->sxFnc.pnodeName->nop == knopVarDecl &&
    -                pnodeFnc->sxFnc.pnodeName->sxVar.pid == pid &&
    -                (pnodeFnc->sxFnc.IsBodyAndParamScopeMerged() || scope->GetScopeType() == ScopeType_Parameter))
    -            {
    -                // Named function expression has its name hidden by a local declaration.
    -                // This is important to know if we don't know whether nested deferred functions refer to it,
    -                // because if the name has a non-local reference then we have to create a scope object.
    -                m_currentNodeFunc->sxFnc.SetNameIsHidden();
    -            }
    -        }
    -
             if (!sym)
             {
                 const char16 *name = reinterpret_cast<const char16*>(pid->Psz());
    @@ -6576,15 +6561,6 @@ bool Parser::ParseFncNames(ParseNodePtr pnodeFnc, ParseNodePtr pnodeFncParent, u
             *pFncNamePid = pidBase;
         }
     
    -    if (fDeclaration &&
    -        pnodeFncParent &&
    -        pnodeFncParent->sxFnc.pnodeName &&
    -        pnodeFncParent->sxFnc.pnodeName->nop == knopVarDecl &&
    -        pnodeFncParent->sxFnc.pnodeName->sxVar.pid == pidBase)
    -    {
    -        pnodeFncParent->sxFnc.SetNameIsHidden();
    -    }
    -
         if (buildAST)
         {
             AnalysisAssert(pnodeFnc);
    
  • lib/Parser/ptree.h+1 4 modified
    @@ -196,7 +196,7 @@ enum FncFlags : uint
         kFunctionIsClassConstructor                 = 1 << 18, // function is a class constructor
         kFunctionIsBaseClassConstructor             = 1 << 19, // function is a base class constructor
         kFunctionIsClassMember                      = 1 << 20, // function is a class member
    -    kFunctionNameIsHidden                       = 1 << 21, // True if a named function expression has its name hidden from nested functions
    +    // Free = 1 << 21,
         kFunctionIsGeneratedDefault                 = 1 << 22, // Is the function generated by us as a default (e.g. default class constructor)
         kFunctionHasDefaultArguments                = 1 << 23, // Function has one or more ES6 default arguments
         kFunctionIsStaticMember                     = 1 << 24,
    @@ -317,7 +317,6 @@ struct PnFnc
         void SetIsLambda(bool set = true) { SetFlags(kFunctionIsLambda, set); }
         void SetIsMethod(bool set = true) { SetFlags(kFunctionIsMethod, set); }
         void SetIsStaticMember(bool set = true) { SetFlags(kFunctionIsStaticMember, set); }
    -    void SetNameIsHidden(bool set = true) { SetFlags(kFunctionNameIsHidden, set); }
         void SetNested(bool set = true) { SetFlags(kFunctionNested, set); }
         void SetStrictMode(bool set = true) { SetFlags(kFunctionStrictMode, set); }
         void SetIsModule(bool set = true) { SetFlags(kFunctionIsModule, set); }
    @@ -358,7 +357,6 @@ struct PnFnc
         bool IsNested() const { return HasFlags(kFunctionNested); }
         bool IsStaticMember() const { return HasFlags(kFunctionIsStaticMember); }
         bool IsModule() const { return HasFlags(kFunctionIsModule); }
    -    bool NameIsHidden() const { return HasFlags(kFunctionNameIsHidden); }
         bool UsesArguments() const { return HasFlags(kFunctionUsesArguments); }
         bool IsDefaultModuleExport() const { return HasFlags(kFunctionIsDefaultModuleExport); }
         bool NestedFuncEscapes() const { return nestedFuncEscapes; }
    @@ -370,7 +368,6 @@ struct PnFnc
             kFunctionNested |
             kFunctionDeclaration |
             kFunctionStrictMode |
    -        kFunctionNameIsHidden |
             kFunctionHasReferenceableBuiltInArguments |
             kFunctionHasNonThisStmt |
             // todo:: we shouldn't accept kFunctionHasAnyWriteToFormals on the asm module, but it looks like a bug is setting that flag incorrectly
    
  • lib/Runtime/ByteCode/ByteCodeGenerator.cpp+4 19 modified
    @@ -2686,27 +2686,12 @@ FuncInfo* PostVisitFunction(ParseNode* pnode, ByteCodeGenerator* byteCodeGenerat
                 Assert(CONFIG_FLAG(DeferNested));
                 byteCodeGenerator->ProcessCapturedSym(sym);
     
    -            if (!top->root->sxFnc.NameIsHidden())
    +            top->SetFuncExprNameReference(true);
    +            if (pnode->sxFnc.pnodeBody)
                 {
    -                top->SetFuncExprNameReference(true);
    -                if (pnode->sxFnc.pnodeBody)
    -                {
    -                    top->GetParsedFunctionBody()->SetFuncExprNameReference(true);
    -                }
    -                if (!sym->GetScope()->GetIsObject())
    -                {
    -                    // The function expression symbol will be emitted in the param/body scope.
    -                    if (top->GetParamScope())
    -                    {
    -                        top->GetParamScope()->SetHasOwnLocalInClosure(true);
    -                    }
    -                    else
    -                    {
    -                        top->GetBodyScope()->SetHasOwnLocalInClosure(true);
    -                    }
    -                    top->SetHasLocalInClosure(true);
    -                }
    +                top->GetParsedFunctionBody()->SetFuncExprNameReference(true);
                 }
    +            byteCodeGenerator->ProcessScopeWithCapturedSym(sym->GetScope());
             }
         }
     
    
  • test/Function/evenMoreFuncExpr3.baseline+1 0 modified
    @@ -9,3 +9,4 @@ obj[0].z : proto[0].z
     obj[0].w : proto[0].w
    
     obj[1].z : undefined
    
     obj[1].w : undefined
    
    +pass
    
    
  • test/Function/evenMoreFuncExpr3.js+8 2 modified
    @@ -40,5 +40,11 @@ var a = function x() {
             "use strict";
    
             x = 1;
    
         };
    
    -}
    
    -
    
    +};
    
    +
    
    +(function __f_997(__v_4351 = function () {
    
    +        WScript.Echo('pass');
    
    +        return __f_997;
    
    +    }()) {
    
    +    function __f_997() {}
    
    +})();
    
    

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

8

News mentions

0

No linked articles in our index yet.