{"record":{"id":"725f37d342a0a93f","repo":"hyperledger/fabric","slug":"chaincode-s-attempted-to-write-to-the-namespace-o","errorCode":null,"errorMessage":"chaincode %s attempted to write to the namespace of LSCC","messagePattern":"chaincode (.+?) attempted to write to the namespace of LSCC","errorType":"validation","errorClass":null,"httpStatus":null,"severity":"critical","filePath":"core/committer/txvalidator/v14/vscc_validator.go","lineNumber":177,"sourceCode":"\t\t\twritesToNonInvokableSCC = true\n\t\t}\n\t}\n\n\t// we've gathered all the info required to proceed to validation;\n\t// validation will behave differently depending on the type of\n\t// chaincode (system vs. application)\n\n\tif !IsSysCC(ccID) {\n\t\t// if we're here, we know this is an invocation of an application chaincode;\n\t\t// first of all, we make sure that:\n\t\t// 1) we don't write to LSCC - an application chaincode is free to invoke LSCC\n\t\t//    for instance to get information about itself or another chaincode; however\n\t\t//    these legitimate invocations only ready from LSCC's namespace; currently\n\t\t//    only two functions of LSCC write to its namespace: deploy and upgrade and\n\t\t//    neither should be used by an application chaincode\n\t\tif writesToLSCC {\n\t\t\treturn peer.TxValidationCode_ILLEGAL_WRITESET,\n\t\t\t\terrors.Errorf(\"chaincode %s attempted to write to the namespace of LSCC\", ccID)\n\t\t}\n\t\t// 2) we don't write to the namespace of a chaincode that we cannot invoke - if\n\t\t//    the chaincode cannot be invoked in the first place, there's no legitimate\n\t\t//    way in which a transaction has a write set that writes to it; additionally\n\t\t//    we don't have any means of verifying whether the transaction had the rights\n\t\t//    to perform that write operation because in v1, system chaincodes do not have\n\t\t//    any endorsement policies to speak of. So if the chaincode can't be invoked\n\t\t//    it can't be written to by an invocation of an application chaincode\n\t\tif writesToNonInvokableSCC {\n\t\t\treturn peer.TxValidationCode_ILLEGAL_WRITESET,\n\t\t\t\terrors.Errorf(\"chaincode %s attempted to write to the namespace of a system chaincode that cannot be invoked\", ccID)\n\t\t}\n\n\t\t// validate *EACH* read write set according to its chaincode's endorsement policy\n\t\tfor _, ns := range wrNamespace {\n\t\t\t// Get latest chaincode version, vscc and validate policy\n\t\t\ttxcc, vscc, policy, err := v.GetInfoForValidate(chdr, ns)\n\t\t\tif err != nil {","sourceCodeStart":159,"sourceCodeEnd":195,"githubUrl":"https://github.com/hyperledger/fabric/blob/2736b63f8fd5932511d56fe68b7039d15977f7f6/core/committer/txvalidator/v14/vscc_validator.go#L159-L195","documentation":"VSCC detected that the application chaincode's write set contains writes to the 'lscc' namespace. Deploy/upgrade are the only legitimate writers of LSCC and are performed by the system, so an application transaction writing to LSCC is rejected with TxValidationCode_ILLEGAL_WRITESET as a security measure (preventing unauthorized chaincode definition changes).","triggerScenarios":"A chaincode performs a PutState on key(s) that land in the lscc namespace — e.g. calling stub.PutState with keys targeting lscc's scope — or a chaincode attempts to emulate deploy/upgrade by writing to lscc directly.","commonSituations":"Malicious or naive chaincode trying to modify its own definition or another chaincode's entry; applications passing user-controlled keys that were crafted to collide with lscc keyspace on old Fabric versions; tests probing system-chaincode writes.","solutions":["Remove any chaincode logic that writes keys into the lscc namespace; use the standard lifecycle (deploy/upgrade) to change chaincode definitions.","Sanitize user-supplied keys in your chaincode so they cannot be crafted to target lscc.","Upgrade channel validation policy / use newer Fabric lifecycle where system-chaincode namespaces are separately enforced."],"exampleFix":"// before\nstub.PutState(\"lscc/mycc/name\", []byte(\"evil\"))\n// after: write only within your own chaincode's namespace\nstub.PutState(\"myccstate\", value)","handlingStrategy":"validation","validationCode":"for _, ns := range txRWSet.NsRwSets {\n    if ns.NameSpace == \"lscc\" {\n        return fmt.Errorf(\"write set contains forbidden write to system chaincode namespace 'lscc'\")\n    }\n}","typeGuard":"func writesOnlyAppNamespaces(rwset *rwset.TxRwSet, appNS []string) bool {\n\tallowed := map[string]bool{}\n\tfor _, n := range appNS {\n\t\tallowed[n] = true\n\t}\n\tfor _, ns := range rwset.NsRwSets {\n\t\tif !allowed[ns.NameSpace] {\n\t\t\treturn false\n\t\t}\n\t}\n\treturn true\n}","tryCatchPattern":"if writesToLSCC {\n    logger.Warnf(\"tx rejected: chaincode %s attempted to write to the namespace of LSCC\", ccID)\n    return peer.TxValidationCode_ILLEGAL_WRITESET, nil\n}","preventionTips":["Never call PutState with keys intended for the lscc keyspace; change definitions via standard lifecycle only.","Sanitize all user-supplied state keys in chaincode code.","Review chaincode diffs for any system-chaincode namespace strings before deployment.","Use the newer Fabric lifecycle (chaincode-as-a-service / _lifecycle) where such writes are structurally prevented."],"tags":["fabric","transaction-validation","security","rwset"],"backgroundTag":"illegal-writeset","analyzedSha":"2736b63f8fd5932511d56fe68b7039d15977f7f6","analyzedAt":"2026-09-04T08:52:36.465Z","contentChangedAt":"2026-09-04T08:52:36.465Z","schemaVersion":2},"datasetVersion":"2026-09-08T10:18:20.063Z"}