Part of the query on has been ignored because of read security rules on error<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Previous releases of ServiceNow had a vulnerability that allowed unauthorized users to potentially access restricted data.Specifically, users with partial access to a table (e.g., "employee")—who could view only certain fields like names but not sensitive information such as Social Security Numbers (SSNs)—could exploit this by submitting queries targeting restricted columns.For example, a user with access only to employee names might run queries such as:• /employee_list.do?sysparm_query=ssnSTARTSWITH1• /employee_list.do?sysparm_query=ssnSTARTSWITH12These queries could allow the user to infer the SSNs of employees by iteratively revealing partial information.To address this issue we have created two defects and the fixes for these defects were implemented in versions W and Y, and back-ported to UP10, VP6, and other relevant patches.The core of the defect fix was to enforce restrictions on column queries for users who do not have read access to sensitive fields like SSNs. However, it is up to individual applications to decide whether these restrictions should apply to their specific tables and features.In some instances, the implemented fixes introduced restrictions that inadvertently broke existing functionality. Users might have encountered messages such as: "Part of the query on xxx has been ignored because of read security rules on xxx.yyyy."The following are workarounds that could be implemented in such cases :1. Add query_match/query_range ACLs to the table.field (preferred solution, though may not be available in older releases).2. Grant the user access to the affected table.field.3. Disable query restrictions for specific table.field pairs.4. Completely disable the feature (not recommended).